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Intelligent  Agents  as  a  Basis  for  Natural  Language  Interfaces 

David  Ngi  Chin 


ABSTRACT 


Typical  natural  language  interfaces  respond  passively  to  the  user’s  commands  and 
queries  They  cannot  volunteer  information,  correct  user  misconceptions,  or  reject  unet^ 
ical  requests.  In  order  to  do  these  things,  a  system  must  be  an  intelligent  agent.  UC 
(UNIX  Consultant),  a  natural  language  system  that  helps  the  user  solve  problems  in  using 
the  UNIX  operating  system,  is  such  an  intelligent  agent. 

The  agent  component  of  UC  is  UCEgo.  UCEgo  provides  UC  with  its  own  goals 
and  plans.  By  adopting  different  goals  in  different  situations,  UCEgo  creates  and  exe¬ 
cutes  different  plans,  enabling  it  to  interact  appropnately  with  the  user.  UCEgo  adop  s 
goals  from  its  themes,  adopts  sub-goals  during  planning,  and  adopts  meta-goals  for  del¬ 
ing  with  goal  interactions.  It  also  adopts  goals  when  it  notices  that  the  user  either  lacks 
necessary  knowledge,  or  has  incorrect  beliefs.  In  these  cases.  UCEgo  plans  to  volunteer 
information  or  correct  the  user’s  misconception  as  appropnate.  These  plans  are  prestored 
skeletal  plans  that  are  indexed  under  the  types  of  situations  in  which  they  are  typically 
useful.  Plan  suggestion  situations  include  the  goal  which  the  plan  is  used  to  achieve,  the 
preconditions  of  the  plan,  and  appropriateness  conditions  for  the  plan.  Indexing  plans  by 
situations  improves  efficiency  and  allows  UC  to  respond  appropnately  to  the  user  in  rea 
time.  Detecting  situations  in  which  a  plan  should  be  suggested  or  a  goal  adopted  is 
implemented  using  if-detected  daemons. 

The  user’s  knowledge  and  beliefs  are  modeled  by  the  KNOME  (KNOwledge  Model 
of  Expertise)  component  of  UC.  KNOME  is  a  double-stereotype  system  which  categor¬ 
izes  users  by  expertise  and  categorizes  UNIX  facts  by  difficulty.  KNOME  deduces  e 
user’s  level  of  expertise  during  the  dialog  with  the  user. 

After  UCEgo  has  selected  a  plan,  it  is  refined  through  the  process  of  answer  expres- 
Sion  by  the  UCExpress  component.  UCExpress  first  prunes  the  answer  to  avoid  telling 
the  user  something  that  the  user  already  knows,  and  to  mark  where  to  use  anaphora  or 
elllDSis  in  generation.  UCExpress  also  uses  specialized  expository  formats  to  express 
different  types  of  information  in  a  clear,  concise  manner.  The  result  is  ready  for  genera- 

tion  into  English. 
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Preface 

A  Short  History  of  UC 

The  original  idea  and  motivation  for  UC,  the  UNIX  Consultant,  came  from  my 
advisor  Robert  Wilensky,  without  whom  this  thesis  and  UC  would  not  exist.  The  very 
first  version  of  UC  was  written  in  early  1982  by  myself.  This  version  of  UC  used  Yigal 
Arens’ s  PHRAN  parser/understander  and  an  early  version  of  his  CLUSTER  Context 
Modeller  ([Arens,  1986]).  It  used  a  Conceptual  Dependency  ([Schank,  1975])  style 
representation,  and  produced  canned  output. 

After  the  success  of  the  initial  version  of  UC,  Yigal  Arens  (the  senior  graduate  stu¬ 
dent  at  the  time)  was  appointed  by  Robert  Wilensky  to  head  implementation  of  the  UC 
project,  and  other  students  were  brought  in  to  work  on  various  aspects  of  UC.  Joe  Faletti 
attempted  to  adapt  his  PANDORA  commonsense  planner  ([Faletti,  1982])  for  UC,  Lisa 
Rau  wrote  an  ellipsis  understanding  component  for  UC  ([Rau,  1985]),  Paul  Jacobs  wrote 
the  PHRED  generator  for  UC  ([Jacobs,  1983]),  Jim  Mayfield  started  work  on  a  goal 
analysis  mechanism  ([Mayfield,  forthcoming]),  and  Jim  Martin  started  work  on  the 
UCTeacher  knowledge  acquisition  component  ([Martin,  1985]).  During  this  time,  UC 
was  adapted  to  run  on  Lhe  PEARL  AI  database  system.  ([Deering  et  al.,  1982]).  My  part 
of  the  project  centered  on  the  knowledge  representation  and  inference  mechanisms  of  UC 

([Chin,  1983a]  and  [Chin,  1983b]). 

This  was  an  exciting  period  for  working  on  UC.  Transcripts  of  electronic  mail  to 
actual  UNIX  Consultants  were  collected  and  analyzed  to  see  how  UC  might  be 
improved.  The  group  even  performed  a  small  experiment  to  see  if  users  would  behave 
differently  when  interacting  with  a  human  than  when  interacting  with  a  program  (simu¬ 
lated  by  a  human  unbeknownst  to  the  subjects).  This  was  described  in  [Chin,  1984].  All 
of  this  culminated  in  a  version  of  UC  that  was  described  in  the  CACM  anicle,  [Wilensky 

et  al.,  1984]. 

Eventually  some  of  the  senior  graduate  students  left  (Yigal  Arens  and  Joe  Faletti), 
and  new  students  joined  the  project.  Charley  Cox  took  over  the  task  of  building  a 
parser/understander  for  UC  ([Cox,  1986]),  Marc  Luria  wrote  a  planner  for  doing  things  in 
UNIX  ([Luria,  1985]  and  [Luria,  forthcoming]),  and  Dekai  Wu  wrote  a  Concretion 
Mechanism  for  doing  certain  low  level  inferences.  At  this  time,  the  KODIAK  represen¬ 
tation  language  ([Wilensky,  1987])  was  developed  at  Berkeley  in  large  part  to  address 
inadequacies  in  the  representation  scheme  of  the  previous  versions  of  UC.  The  initial 
implementation  of  KODIAK  was  wrinen  by  Peter  Norvig  for  his  FAUSTUS  story  under¬ 
stander  ([Norvig,  1986])  and  this  was  adapted  for  use  in  UC.  Also  during  this  penc^, 
Lisa  finished  her  Master’s  thesis  and  left;  Paul  Jacobs  finished  his  Ph.  D.  thesis  on  e 
KING  natural  language  generator  ([Jacobs,  1986])  and  left,  leaving  Anthony  Albert  to 
continue  work  on  generation  in  UC.  The  implementation  of  UC  was  headed  at  y^ous 
times  by  Rick  Alterman  (a  postdoctoral  fellow  at  Berkeley),  Marc  Luria,  or  myself.  My 
work  on  UC  shifted  to  the  areas  presented  in  this  thesis  (e.  g.  [Chin,  1986]^  This  penod 
of  UC’s  development  culminated  in  the  Berkeley  Technical  Report,  [Wilensky  et  al., 

1986]. 
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Chapter  I 
Introduction 


1.  Consultation  Programs 


Consider  the  problem  of  building  a  program  that  simulates  a  human  consultant.  A 
user  would  be  able  to  come  up  to  such  a  program  and  obtain  advice  in  the  program’s 
domain  of  expertise  by  entering  queries  in  English  (or  some  other  natural  language).  The 
consultant  program  would  then  provide  solutions  in  English.  A  user  might  ask  for  advice 
about  how  to  do  things,  for  definitions  of  terminology,  or  for  advice  in  solving  problems. 
In  short,  this  program  would  behave  like  a  real  human  consultant. 

In  order  to  build  such  a  system,  one  needs  to  satisfy  at  least  three  requirements. 
First,  the  computer  system  needs  to  be  able  to  understand  the  user’s  queries.  Next,  the 
program  must  be  able  to  solve  the  user’s  problems  and  formulate  an  answer.  Finally,  the 
system  must  be  able  to  convey  the  solution  to  the  user  in  a  clear,  concise  manner.  Need¬ 
less  to  say,  there  are  many  difficult  and  unsolved  problems  in  each  of  these  areas.  The 
first  requirement,  understanding  the  user,  involves  the  whole  of  natural  language  under¬ 
standing,  a  difficult  area  of  artificial  intelligence  research.  The  second  requu-ement, 
problem  solving,  has  a  long  continuing  history  of  research  in  AI.  The  last  requirement, 
communicating  the  answer  to  the  user,  has  a  shorter  history  of  research  in  AI,  but  is  no 
less  difficult  a  problem. 

However,  even  if  all  of  the  problems  in  each  of  the  three  areas  were  to  be  solved, 
and  one  could  build  a  natural  language  consultation  system  that  did  each  of  the  three 
tasks  perfectly,  that  would  still  not  be  enough  for  a  good  natural  language  consultation 
system.  A  good  consultation  system  also  needs  to  be  able  to  take  the  initiative  in  a  dialog 
with  the  user,  rather  than  always  responding  passively  to  the  user.  For  instance,  consider 
the  following  user  interaction  with  a  hypothetical  program  that  provides  advice  on  using 
the  UNIX'  operating  system: 

User:  What  does  Is  -v  do? 

Program:  It  lists  the  contents  of  your  current  directory. 

The  hypothetical  program  gives  an  answer  that  is  literally  correct,  since  the  Is  com¬ 
mand  actually  ignores  inappropriate  flags  such  as  -v.  However,  a  consultant  that  pro¬ 
vides  only  the  above  answer  has  failed  to  correct  the  user’s  incorrect  preconception  that 
the  Is  command  has  a  -v  flag.  So,  although  the  user  did  not  specifically  ask  whether  Is 
has  a  -V  flag,  a  good  consultant  would  not  fail  to  provide  the  information  that  in  fact  Is 
does  not  have  such  a  flag.  Such  a  response  is  shown  in  the  next  dialog: 


'  UNIX  is  a  trademaik  of  Bell  Laboratories. 
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User:  What  does  Is  -v  do? 

Program:  There  is  no  -v  option  for  Is. 


This  is  a  better  answer  even  though  it  literally  does  not  answer  the  user  s  question. 
In  deciding  to  ignore  the  user’s  direct  question  and  shift  its  attention  to  the  user  s 
misconception,  the  program  has  taken  the  initiative  in  the  dialog.  This  shows  that  a  good 
consultant  cannot  just  passively  respond  to  the  user;  rather,  it  must  have  its  own  agenda. 

In  the  previous  dialog,  the  better  answer  requires  that  the  program  realize  that  the 
user  has  a  misconception.  To  do  this,  the  system  must  first  infer  that  the  user  believes 
that  Is  has  a  -v  option  and  then  realize  that  the  user’s  belief  conflicts  with  the  program  s 
knowledge.  So,  in  general,  a  good  consultant  system  must  also  model  the  user’s 

knowledge  and  beliefs. 

Even  after  a  consultant  system  realizes  that  the  user  has  a  misconception,  it  must 
decide  how  to  deal  with  the  misconception.  In  the  above  example,  the  system  decides 
that  it  should  inform  the  user  of  the  facts  in  order  to  correct  the  user’s  misconception.  In 
other  cases,  the  system  may  choose  to  ignore  the  misconception,  as  in  the  following 


scenario: 


T 


How  can  I  delete  someone  else’s  file  when  I  don’t  have  wTit 


permission  on  the  file? 

Program:  I  will  not  help  you  delete  someone  else’s  file  because  that  is  unethi¬ 
cal. 


In  the  user’s  statement  above,  the  user  has  assumed  that  one  needs  write  permission 
on  the  file  to  delete  it.  This  is  not  true.  Rather,  one  needs  write  permission  on  the  parent 
directory  to  delete  the  file.  Regardless  of  what  is  the  correct  precondition,  the  program 
decides  not  to  help  the  user  because  of  ethical  considerations.  This  also  means  that  the 
program  decides  not  to  correct  the  user’s  misconception,  so  as  to  avoid  helping  the  user 
delete  someone  else’s  file.  This  is  an  example  of  a  decision  by  a  consultant  program  to 
be  uncooperative. 

Of  course  a  good  consultant  program  cannot  arbitrarily  decide  to  be  uncooperative. 
In  the  previous  case,  the  decision  to  be  uncooperative  was  based  on  the  fact  that  Ae 
user’s  goal  of  deleting  someone  else’s  file  conflicts  with  the  program  s  goal  of  preserving 
all  users’  files.  In  this  case,  the  program’s  goal  of  preserving  files  wins  out  over  the 
program’s  desire  to  help  the  user  who  asked  the  question.  These  sorts  of  goals  and  goal 
interactions  are  needed  to  guide  a  consultant  system  properly. 

After  a  course  of  action  has  been  determined,  it  must  be  earned  out.  Even  in  the 
simplest  case  where  the  program  just  answers  the  user’s  question,  there  are  still  many 
ways  to  express  the  answer  to  the  user.  In  the  following  scenario,  FI  and  F2  represent 
two  possible  formats  for  expressing  the  answer  to  the  user’s  question. 
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User:  How  can  I  change  the  group  protection  of  a  file? 

FI:  To  change  the  permission  of  a  file,  type  ‘chmod’  followed  by  one  or 

more  spaces  or  tabs  followed  by  ‘g’,  followed  by  either  ‘+  for  add  per¬ 
mission  or  for  remove  permission,  followed  by  the  t^e  of  permis¬ 
sion,  which  is  either  ‘r’  for  read  permission,  ‘w’  for  write  permission, 
or  ‘x’  for  execute  permission,  followed  by  or  more  spaces  or  tabs  fol¬ 
lowed  by  the  name  of  the  file  to  be  changed,  followed  by  a  carnage  re¬ 
turn. 

F2:  Use  chmod. 

For  example,  to  add  group  read  permission  to  the  file  foo, 
type  ‘chmod  g+r  foo’. 

The  first  form  of  the  answer,  FI,  is  correct  and  quite  general,  but  it  is  also  so  ver¬ 
bose  that  it  is  undecipherable.  On  the  other  hand,  the  second  form  of  the  answer,  F2  is 
succinct  and  gives  the  user  information  in  an  easily  readable  form,  but  it  is  considerably 
less  general.  In  fact  the  second  format  is  somewhat  inaccurate,  since  the  example  strictly 
applies  only  to  adding  group  read  permission  to  the  file  foe.  It  is  up  to  the  reader  to  use 
analogous  reasoning  to  apply  this  to  other  cases.  Despite  this  lack  of  generality,  the 
second  answer  form  is  clearly  superior  to  the  first.  Note  that  the  second  form  requires 
additional  computation  to  transform  the  general  solution  of  FI  into  an  example.  A 
natural  language  system  needs  to  incorporate  knowledge  about  when  and  how  to  use  spe¬ 
cial  presentation  formats  like  examples  to  convey  information  more  clearly  to  the  user. 


2.  Intelligent  Agents 

The  examples  in  the  previous  section  have  shown  that  a  good  computer  consultation 
system  cannot  be  just  a  passive  question-answering  system.  Rather,  the  consultant  sys¬ 
tem  must  often  take  the  initiative.  This  is  because  consultant  systems  generally  have 
greater  knowledge  in  their  field  of  expertise  than  users.  As  in  the  example  in  the  previ¬ 
ous  section,  the  consultant  may  sometimes  need  to  take  the  initiative  in  order  to  correct  a 
user’s  misconceptions.  Also,  the  consultant  may  need  to  take  the  initiative  in  order  to 
provide  needed  information  that  the  user  did  not  explicitly  ask  for.  In  fact,  the  user  often 
does  not  even  realize  that  such  information  is  pertinent,  so  will  never  ask  for  it.  A  com¬ 
puter  consultant  system  needs  to  have  the  human-like  capability  of  taking  the  initiative  in 
a  dialog  rather  than  always  responding  to  the  user  passively. 

Previous  efforts  in  natural  language  systems  that  take  the  initiative  have  resul^d  in 
programs  capable  of  “mixed-initiative”  dialogs.  Among  the  first  of  these,  the  SCHO¬ 
LAR  system  ([Carbonell,  1970a&b])  for  CAI  (Computer-Aided  Instruction),  could  take 
the  initiative  to  test  the  user  on  facts  in  its  knowledge  base.  It  also  allowed  die  user  to 
query  the  system  about  facts  in  its  knowledge  base.  This  type  of  “mixed-initiative 
works  only  for  limited  situations  such  as  mutual  quizzing.  A  system  based  on  answenng 
or  generating  quiz  questions  cannot  be  adapted  to  help  the  user  solve  problems,  volunteer 
information  pertinent  to  the  user’s  problems,  or  detect  misconceptions  evident  from  the 
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user’s  questions  (as  opposed  to  wrong  answers  from  the  user). 

More  recent  efforts  have  followed  one  of  two  approaches  to  the  problem  of  taking 
the  initiative  in  a  dialog:  script-based  or  frame-based.  In  the  script-based  approach,  the 
system  follows  a  set  script  of  interchanges  with  the  user.  For  example,  the  hotel  reserva¬ 
tion  application  of  the  HAM-ANS  system  ([Hoeppner  et  al.,  1984])  used  a  fixed  series  of 
exchanges  in  which  the  system  has  the  initiative  part  of  the  time.  The  other  appr(^ch, 
frame-based  initiative,  is  exemplified  by  the  GUS  system  ([Bobrow  et  al.,  1977])  GUS 
took  the  initiative  in  the  dialog  when  it  needed  to  fill  in  information  for  a  slot  in  a  frame. 
Typically,  the  frame  would  represent  information  that  GUS  needed  in  order  to  address 
the  user’s  problem.  Each  of  these  approaches  works  to  provide  programs  with  the  capa¬ 
bility  to  take  the  initiative  in  limited  situations.  However,  none  is  pneral  enough  to 
cover  other  types  of  situations  where  a  program  should  take  the  initiative.  For  example, 
neither  approach  would  allow  a  program  to  take  the  initiative  to  correct  a  user  miscon¬ 
ception. 

The  approach  that  I  take  is  to  view  the  program  as  an  agent .  That  is,  a  consultation 
system  should  be  viewed  as  a  system  that  can  perform  actions.  For  a  natural  language 
consultation  system,  acting  consists  of  mostly  speech  acts  ([Austin,  1962]  and  [Searle, 
1969]),  i.  e.  acting  by  communicating  with  the  user.  Within  this  paradigm,  taking  the  ini¬ 
tiative  in  a  dialog  translates  into  acting  without  the  guidance  of  the  user,  ^n  agent  that 
has  this  capability  of  taking  the  initiative  is  called  an  autonomous  agent. 

A  rational  agent  is  an  agent  that  behaves  rationally.  In  Al  programs,  much  as  in 
popular  psychology,  this  usually  means  attributing  reasonable  plans  and  goals  to  the 
agent  in  question.  For  example,  PAM  ([Wilensky,  1978])  understood  stories  involving 
rational  agents  by  analyzing  the  goals  and  plans  of  the  characters.  Likewise,  TALE- 
SPIN  ([Meehan,  1976])  used  plans  and  goals  to  create  simple  stories  with  rational  agents 
as  characters.  In  the  problem  solving  domain,  robot  planning  programs  (e.  g.  [Fikes  and 
Nilsson,  1971]  and  [Sacerdoti,  1974])  have  shown  that  planning  is  a  good  paradigm  for 
prograniming  robots  as  rational  agents.  In  the  realm  of  conversation,  [Hobbs  and  Evans, 
1980]  have  argued  that  human  conversation  fits  such  a  paradigm.  So,  a  program  that 
contains  reasonable  plans  and  goals  and  that  is  guided  by  those  plans  and  goals  can  be 
considered  a  rational  agent. 

Within  the  planning  paradigm,  a  rational  autonomous  agent  is  one  that  contains 
plans  and  goals  that  allow  the  agent  to  take  the  initiative  in  appropriate  situations.  The 
central  problem  in  building  autonomous  agents  is  determining  which  situations  require 
the  agent  to  take  the  initiative.  For  a  rational  autonomous  agent  that  is  based  on  the  plan¬ 
ning  paradigm,  this  problem  translates  to  the  problem  of  determining  appropnate  goals 
for  the  planner.  Such  a  process  is  called  goal  detection  ([Wilensky,  1983]). 

After  a  rational  autonomous  agent,  henceforth  called  an  intelligent  agent,  has 
detected  appropriate  goals,  it  is  up  to  the  planner  of  the  intelligent  agent  to  formulate  a 
plan  to  satisfy  these  goals  and  then  carry  out  the  plan.  Much  work  has  been  done  in  Al  in 
the  area  of  planning  where  the  goals  of  the  planner  are  provided  by  the  operator.  For 
example,  [Newell  and  Simon,  1972]  formulated  “means-ends”  analysis  as  a  general  stra¬ 
tegy  for’achieving  given  “ends”  or  goals.  However,  the  robot  planning  programs  all 
assumed  that  the  goals  are  given  by  the  users.  Likewise  in  TALE-SPIN,  the  progra^er 
provided  the  initial  goals  of  the  characters.  For  story  understanding,  PAM  was  able  to 
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recognize  a  character’s  goals  when  directly  stated  in  the  narrative,  or  when  the  goal  could 
be  inferred  from  the  characters’  stated  actions  based  on  the  assumption  that  the  actions 
were  part  of  the  character’s  plan.  As  [Carbonell,  1982]  points  out,  none  of  these  systems 
have  systematically  addressed  the  problem  of  goal  detection,  which  is  essential  for  build¬ 


ing  intelligent  agents. 

The  PANDORA  planner  ([Faletti,  1982]),  which  implemented  some  of  the  com- 
monsense  planning  ideas  presented  in  [Wilensky,  1983],  did  perform  some  pal  detec¬ 
tion.  PANDORA  detected  goals  when  actual  or  projected  states  conflicted  with  goals  or 
plans.  Also,  certain  goals  were  attached  to  the  frames  describing  situatiop.  For  exam¬ 
ple,  the  goal  of  “find  out  about  the  world’’  was  attached  to  the  “morning”  frame,  which 
meant  that  PANDORA  would  try  to  read  a  newspaper  in  the  morning.  However,  except 
for  very  simple  frames,  PANDORA  did  not  address  the  problem  of  when  is  it  proper  to 
invoke  frames  and  their  associated  goals.  Also,  because  PANDORA  existed  in  a  self- 
contained  simulated  world,  it  did  not  address  the  problem  of  detecting  goals  when  the 
system  must  interact  with  real  users. 

In  order  to  interact  intelligently  with  its  environment,  an  agent  needs  knowledge 
about  its  environment.  Such  knowledge  is  needed  for  the  agent  to  respond  properly  to 
stimuli,  which  for  a  rational  agent  is  equivalent  to  detecting  the  right  goals  and  carrying 
out  the  right  plans.  In  the  case  of  an  agent  that  is  a  computer  consultation  system,  the 
environment  consists  of  a  discourse  with  the  user  on  the  system’s  domain  of  expertise. 
Thus,  the  intelligent  agent  needs  to  have  information  about  its  domain  of  expertise  and 
about  its  user.  A  computer  consultation  system  could  not  be  built  without  some  informa¬ 
tion  about  its  domain;  however,  information  about  its  user  is  less  commonly  found  in 
such  systems.  Yet,  a  model  of  the  user  is  essential  for  a  computer  consultation  system 
that  attempts  to  embody  an  intelligent  agent. 

This  thesis  addresses  the  problem  of  building  a  natural  language  computer  consulta¬ 
tion  system  that  behaves  as  an  intelligent  agent.  The  ideas  presented  in  this  thesis  are 
implemented  in  the  UC  (UNIX  Consultant)  system,  which  embodies  an  intelligent  agent. 


3.  UC,  the  UNDC  Consultant 

UC  (UNIX  Consultant)  is  an  interactive  natural  language  consultant  system  for  the 
UNIX  operating  system.  UC  is  able  to  provide  information  about  how  to  do  things  in 
UNIX,  provide  definitions  about  UNIX  or  general  operating  system  terminology,  and 
provide  help  in  debugging  problems  with  using  UNIX. 

The  main  purpose  of  the  UC  project  is  to  investigate  fundamental  issues  of  AI  in 
natural  language  processing,  knowledge  representation,  planning  and  problem  solving, 
and  building  integrated  natural  language  interfaces.  The  UC  program  serves  as  a  test-bed 
for  ideas  on  how  to  approach  these  problems.  Successful  ideas  are  earned  over  to 
succeeding  versions  of  UC,  while  unsuccessful  ideas  are  rethought.  Although  UC  is 
completely  implemented,  it  is  still  only  an  extendible  prototype  and  does  not  contain 
enough  knowledge  to  be  usable  in  the  real  world.  Indeed,  producing  a  usable  product  is 
an  inappropriate  pursuit  for  a  research  institution;  so,  UC  is  only  implemented  in  enough 
breadth  to  validate  its  research  ideas  and  to  show  that  a  real  system  might  actually  be 


-6- 


constructed  along  the  lines  suggested  by  the  research. 

A  short  overview  of  UC  follows.  For  more  details  on  other  aspects  of  UC  not  dis¬ 
cussed  in  this  thesis,  the  reader  is  referred  to  [Wilensky  et  al.,  1986]  and  [Wilensky  et  al., 
1984]. 

In  a  typical  UC  session,  the  user  types  questions  in  English  to  UC,  and  UC  responds 
to  the  user  in  EngUsh.  A  schematic  diagram  of  the  flow  of  information  among  UC’s  vari¬ 
ous  components  is  shown  in  Figure  1.1.  The  input  to  UC  is  analyzed  by  the  ALANA 
language  analysis  component  of  UC,  which  produces  a  semantic  representation  of  the 
input.  This  representation  is  in  the  form  of  a  KODIAK  network  (see  Appendix  A).  Next, 
UC’s  Concretion  Mechanism  performs  concretion  inferences  ([Wilensky,  1983]  and 
[Norvig,  1983])  based  on  the  semantic  network.  Concretion  is  the  process  of  infen^g 
more  specific  interpretations  of  the  user’s  input  than  might  strictly  be  correct  on  a  logical 
basis.  Such  inferences  might  be  motivated  by  the  context  of  the  utterance  or  by  cultur¬ 
ally  accepted  usage  biases.  After  concretion,  the  modified  KODIAK  network  is  passed  to 
PAGAN,  UC’s  goal  analysis  component.  PAGAN  deduces  the  user’s  actual  goals.  This 
includes  inferring  the  user’s  high-level  goals  as  well  as  the  user’s  immediate  goals. 
PAGAN  also  handles  phenomena  such  as  indirect  speech  acts. 

After  the  initial  analysis  of  the  user’s  input,  the  UCEgo  component  of  UC  decides 
how  UC  should  respond.  UCEgo  is  the  component  of  UC  that  implements  an  intelligent 
a^^ent.  It  first  determines  what  UC’s  own  goals  should  be,  then  formulates  a  plan  to 
achieve  these  goals,  and  finally  carries  out  this  plan.  UCEgo  detects  its  own  goals  based 
on  the  present  situation,  which  may  include  such  varied  factors  as  the  user  s  goals,  the 
user’s  utterances,  as  well  as  UC’s  own  goals,  knowledge,  and  internal  state. 

Part  of  UCEgo’ s  response  may  involve  calling  on  the  services  of  the  UCPlanner 
component  of  UC.  UCPlanner  is  a  UNIX  domain  planner  that  creates  plans  for  doing 
things  in  UNIX.  Another  component  of  UC  that  may  be  called  by  UCEgo  is  UCExpress. 
UCExpress  uses  the  process  of  answer  expression  to  refine  the  communicative  plans  pro¬ 
duced  by  UCEgo.  First,  UCExpress  prunes  extraneous  concepts  from  the  answer,  either 
when  the  user  already  knows  the  concepts,  or  when  the  concepts  either  are  already  part  of 
the  conversational  context.  Next  UCExpress  uses  specialized  formats  such  as  similes  and 
examples  to  express  information  to  the  user  in  a  clear  and  concise  manner.  The  result  of 
UCExpress’  processing  is  an  annotated  KODIAK  network  that  is  ready  for  generation 
into  English  by  the  UCGen  tactical  level  generator. 

Another  imponant  part  of  UC  is  KNOME,  the  user  modeling  component.  KNOME 
encodes  the  knowledge  and  beliefs  of  the  user.  It  also  deduces  what  the  user  knows  and 
believes  based  on  UC’s  conversation  with  the  user.  KNOME  also  models  the  extent  of 
UC’s  own  knowledge  of  UNIX.  This  is  useful  in  differentiating  between  actual  user 
misconceptions  and  cases  in  which  UC’s  knowledge  base  is  incomplete. 

This  thesis  is  mainly  concerned  with  the  UCEgo,  UCExpress,  and  KNOME  com¬ 
ponents  of  UC.  UCEgo  is  composed  of  two  parts,  a  goal  detector  and  a  plan 
selector/executor.  The  goal  detector  detects  appropriate  goals  for  UC  according  to  the 
situation.  The  plan  selector/executor  then  takes  these  goals  and  plans  for  them,  eventu¬ 
ally  executing  the  plans.  Goal  detection  in  UCEgo  is  described  in  Chapter  III,  and  plan 
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selection/execution  is  discussed  in  Chapter  FV.  Refinement  of  the  plans  by  UCExpress  is 
described  in  Chapter  V,  and  KNOME,  the  user  modeling  component,  is  described  in 
Chapter  11. 

3.1.  A  Session  with  UC 

To  see  how  UCEgo  works  in  more  detail,  consider  the  following  trace  of  a  UC  ses¬ 
sion.  In  the  trace,  actual  output  from  UC  to  the  user  is  shown  in  Bold  Courier  font, 
trace  output  from  UC  is  shown  in  courier  font,  and  input  from  the  user  to  UC  is 
shown  in  obiicjue  Courier  font.  Explanations  of  the  processing  are  in  normal  font 
and  are  separated  by  half  lines  from  the  actual  trace. 

In  the  trace  output,  an  represents  an  abbreviation  by  UC  of  a  concept  that  was 
completely  specified  earlier  in  the  trace  (UC  marks  previously  printed  concepts  so  that  it 
will  know  when  it  can  abbreviate).  Where  parts  of  the  trace  are  left  out  for  brevity,  this 
is  indicated  by  three  dots.  In  order  to  fit  the  trace  on  the  page,  the  indentation  of  some  of 
the  LISP  forms  were  adjusted  by  hand.  These  conventions  will  be  used  throughout  the 
rest  of  this  thesis  for  trace  output  from  UC. 

The  following  trace  demonstrates  what  UC  can  do,  concentrating  on  the  capabilities 
of  the  UCEgo,  KNOME,  and  UCExpress  components.  In  the  trace,  the  user  asks  UC  six 
questions.  The  somewhat  lengthy  trace  of  processing  the  user’s  first  question  illustrates 
some  of  the  more  basic  capabilities  of  the  system,  including:  how  KNOME  deduces  what 
the  user  knows  from  the  user’s  query;  how  UCEgo  detects  goals,  plans  for  those  goals, 
and  executes  the  resultant  plans;  and  how  UCExpress  refines  those  plans  through  the  pro¬ 
cess  of  answer  expression. 

The  next  five  examples  demonstrate  some  of  the  more  exotic  capabilities  of  UC. 
The  second  query  shows  UC  correcting  a  user  misconception,  and  the  third  example 
illustrates  the  use  of  an  example  format  by  UCExpress  to  more  clearly  convey  informa¬ 
tion  to  the  user.  UC’s  reply  to  the  user’s  founh  question  shows  UC  volunteering  infor¬ 
mation  to  the  user,  and  the  user’s  followup  question  elicits  an  answer  in  UCExpress 
simile  format.  Finally,  the  last  example  shows  UCEgo  refusing  to  help  the  user  with  an 
unethical  request. 


Welcome  to  UC  (Unix  Consultant)  version  3.23 
To  a  '#'  proiqst,  please  type  in  your  questions 
about  the  UNIX  file  system  in  English. 

To  leave,  just  type  ' *D'  or  ' (exit) ' . 

Hi. 

How  can  I  help  you? 


This  first  user  query  is  used  to  show  some  of  the  more  basic  features  of  UC. 
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#  How  can  I  find  out  the  protection  of  a  file? 

The  parser  produces: 

(ASKIO  (listenerlO  =  UC) 

(speakerlO  =  *USER*) 

^^^Q5ESoN10~(what-isl0  =  {ACTION14?  (actorl4  =  *USER*)  )  )  )  )  ) 

( informat ion-act ion  0  ? 

(actorO-1  =  *USER*) 

(INFORMATION-ACTION-ef fectO  = 

( INFORMAT lON-EFFECTl ? 

'"""siATE-iF-^ILEO  (file-StateO  =  FILE-PROTECTIONl) 

(state-fileO-O  =  FILE4?))) 

(informantl  =  (actorO-1  =  aspectual-of 

(INFORMATION-ACTIONO?  &))))) 

(causeO-0  =  (ACTION14?  &) ) ) 


The  first  step  in  UCs  processing  is  done  by  UC's  parser/understander  component  which 

produces  a  KODIAK  semantic  network  representation  of  the  meMing  of  the  user  s  utK 

ances.  The  KODIAK  representation  system  used  in  UC  is  described 

above  linearized  form  of  KODIAK  represents  the  fact  *0  use-  (  ““ 

fASKlO)  UC  a  question  about  what  is  the  referent  of  ACTIO  .  '  v. 

cause  of  INFOIUvlATION-ACTIONO,  which  represents  the  user 

protection  (FILE-PROTECTIONl)  state  (STATE-OF-FILEO)  of  some  file  (FILE4). 

UCEgo  detects  the  following  concepts. 

FILE-PROTECTIONl 

and  asserts  the  following  concept  into  the  database. 

(user-knows6  (uk-fact6  =  FILE-PROTECTIONl) 

{uk-user6  =  *USER*) 

(uk-truth-val6  =  TRUE) ) 


KNOME : 
KNOME: 

KNOME : 
KNOME: 
KNOME : 

KNOME : 

KNOME : 


Asserting  *USER*  knows  FILE-PROTECTIONl 
Since  FILE-PROTECTIONl  is  a  FILE-PROTECTION, 
asserting  *USER*  knows  FILE-PROTECTION 

FILE-PROTECTION  has  difficulty  MUNDANE,  so  deducing: 
ruling  out  *USER*  =  NOVICE 

*USER*  is  SOMEWHAT-UNLIKELY  to  be  BEGINNER 

=>  likelihood (*USER*  =  BEGINNER)  =  UNCERTAIN 

*USER*  is  SOMEWHAT-LIKELY  to  be  INTERMEDIATE 

=>  likelihood (*USER*  =  INTERMEDIATE)  =  SOMEWHAT-LIKELY 

*USER*  is  LIKELY  to  be  EXPERT 

=>  likelihood (*USER*  =  EXPERT)  =  LIKELY 
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KNOME,  the  user  modeling  component  of  UC,  is  described  in  Chapter  n.  KNOME 
models  the  user’s  knowledge  in  the  UNIX  domain.  It  infers  individual  facts  about  what 
the  user  does  or  does  not  know  from  what  the  user  says,  and  then  combine  this  evidence 
to  figure  out  the  user’s  level  of  expertise  in  using  UNIX.  Here,  from  the  fact  that  the  user 
correctly  uses  the  concept  of  FILE-PROTECTION  in  a  sentence,  KNOME  infers  that  the 
user  must  know  that  concept.  This  deduction  allows  KNOME  to  make  further  inferences 
about  the  user’s  level  of  expertise  in  the  UNIX  domain.  Since  FILE- PROTECTION  is  a 
concept  of  a  mundane  difficulty  level,  KNOME  infers  Aat  the  user  could  not  be  a  novice, 
is  somewhat  unlikely  to  be  a  beginner,  is  somewhat  likely  to  be  an  intermediate,  and  is 
likely  to  be  an  expert  (actually,  although  an  expert  is  likely  to  know  about  file  protection, 
an  expert  would  also  know  how  to  change  a  file’s  protection  and  would  not  ask  such  a 
question;  this  latter  inference  appears  later  in  the  trace). 

Ordinarily,  the  inferences  that  KNOME  makes  about  the  user’s  level  of  expertise  are 
immediately  useful  to  UC  in  forming  its  answer.  However,  in  this  particular  case,  these 
inferences  will  not  be  used  until  UC  processes  the  user’s  next  query. 


The  goal  analyzer  produces: 

( (HAS-GOAL-gaO 

(planner-gaO  =  *USER*) 

(goal-gaO  =  (KNOW-gaO?  (knower-gaO  =  *USER*) 

(fact-gaO  =  (ACTION14?  &)))))) 


Based  on  the  fact  the  user  asked  UC  a  question  about  how  to  do  something,  UC  s  goal 
analysis  component  infers  that  the  user’s  goal  is  to  know  ACTION  14,  which  represents 
how  to  find  out  the  protection  of  a  file. 


UCEgo:  suggesting  the  plan: 

{PLANFOR73  (goals73  =  (HELPS  (helpeeS  =  *USER*) 

(helpers  =  UC) ) ) 

(plan73  =  (SATISFY6  (need6  =  (KNOW-gaO?  &) ) 

(actorG  =  UC) ) ) ) 

based  on  the  situation: 

(UC-HAS-GOAL63  (status63  =  ACTIVE)  (goal63  =  (HELPS  &) ) ) 
(HAS-GOAL-gaO  &) 


UCEgo  suggests  specific  plans  when  it  encounters  certain  specialized  situations .  In  this 
case  UCEgo  suggests  that  a  plan  (PLANFOR73)  for  helping  the  user  is  to  satisfy  the 
user’s  goal  of  knowing  (KNOW-gaO)  how  to  find  out  the  protection  of  a  file.  In  general, 
UCEgo  suggests  the  plan  of  helping  the  user  by  satisfying  the  user  s  goal  of  knowing, 
whenever  UCEgo  encounters  a  situation  in  which  UC  has  the  goal  of  helping  the  user, 
and  the  user  has  the  goal  of  knowing  something.  UC’s  goal  of  helping  the  user 


f 
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originated  at  the  start  of  the  session  from  UC’s  role  theme  of  being  a  UNIX  consultant. 
Themes  and  the  goals  which  arise  from  themes  are  discussed  in  Chapter  III,  Section  2. 
The  suggestion  of  plans  for  carrying  out  these  goals  is  described  in  Chapter  FV,  Section 
2.  The  actual  detection  of  situations  is  performed  by  if-detected  daemons,  which  are 
described  in  Chapter  VI. 


UCEgo  detects  the  following  concepts: 

(HAS-GOAL-gaO  &) 

and  asserts  the  following  concept  into  the  database. 
(user-knows7  (uk-user7  =  *USER*) 

(uk-truth-val7  =  FALSE) 

(uk-fact7  =  (ACTI0N14?  &))) 

KNOME :  Asserting  *USER*  does  not  know  ACTION13? 


The  fact  that  the  user  wants  to  know  how  to  find  out  the  protection  of  a  file  allows 
KNOME  to  infer  that  the  user  does  not  know  how.  Since  “how  to  find  out  the  protection 
of  a  file”  is  a  description  of  an  object  rather  than  an  actual  object,  KNOME  does  not 
immediately  use  this  fact  to  infer  the  user’s  level  of  expertise  as  it  did  when  it  inferred 
that  the  user  knew  the  concept  of  file  protection.  Later,  after  UC  identifies  the  referent  of 
the  description,  KNOME  will  then  make  additional  inferences  about  the  user’s  level  of 
expertise. 


UCEgo  detects  the  following  concepts: 

(UC-HAS-GOAL63  &) 

(PLANFOR73  &) 

and  asserts  the  following  concept  into  the  database: 
(UC-HAS-INTENTION9  (intention9  =  (SATISFYS  &) )  (status9  =  ACTIVE) ) 


Here,  UCEgo  adopts  the  intention  of  carrying  out  the  plan  for  helping  the  user  (inten¬ 
tions’ are  described  in  Chapter  IV,  Section  3.1).  An  intention  has  two  possible  meanings 
depending  upon  the  type  of  plan.  If  the  plan  is  a  series  of  actions,  then  the  intention 
means  that  UCEgo  has  scheduled  the  plan  for  execution  during  its  plan  execution  stage 
(see  Chapter  IV,  Section  3).  On  the  other  hand,  if  the  plan  is  to  satisfy  some  state  (as  in 
this  case),  then  the  intention  means  that  UCEgo  will  adopt  that  state  as  a  sub-goal  and 
continue  its  planning  process.  This  is  shown  below:  UCEgo  adopts  the  sub-goal  of  hav¬ 
ing  the  user  know  how  to  find  out  the  protection  of  a  file. 


UCEgo:  detected  the  goal: 

(UC-HAS-GOAL66  (goal66  =  (KNOW-gaO?  &) ) ) 
from  the  situation: 
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(UC-HAS-INTENTI0N9  &) 

UCEgo  detects  the  following  concepts: 

(PLANFOR-gal  (goals-gal  =  (INFORMATION-EFFECTl?  &) ) 
(plan-gal  =  (ACTI0N14?  &))) 

(UC-HAS-GOAL66  &) 

and  asserts  the  following  concept  into  the  database: 
(UNIX-planner2  (user-goals2  =  (INFORMATION-EFFECTl?  &))) 


Since  UC  has  the  goal  of  knowing  a  plan  for  something,  it  calls  the  UNIX  domain 
planner  component  of  UC  in  case  the  domain  planner  can  produce  a  plan  for  UC.  This 
type  of  reasoning  is  described  in  Chapter  IV,  Section  3.2. 


The  planner  is  passed: 

((INFORMATION-EFFECTl?  &)) 

The  planner  produces : 

(PLANFOR460  (goals460  =  (INFORMATION-EFFECTl?  &)) 

(plan460  =  UNIX-LS-l-COMMANDO) ) 

( LS-1 -HAS -FORMAT 0 

(LS-l-HAS-FORMAT-COimiandO  =  UNIX-LS-l-COMMANDO) 
(LS-l-HAS-FORMAT-formatO  = 

(LS-l-FORMATl  (LS-1-FORMAT-Stepl  = 

(SEQUENCE30  (next30  =  -1) 

(step30  =  Is) ) ) ) ) ) 

(HAS-EFFECT120 

(conimand-of-effectl20  =  UNIX-LS-l-COMMANDO) 

(ef fect-of-commandl20  =  (LIST-EFFECTIO 

(list-objectlO  =  FILE-PROTECTIONO? ) ) ) ) 

(HAS-OPTION20  (coinmand-of-option20  =  UNIX-LS-l-COMMANDO) 

(option20  =  -1-OPTIONO)) 

( HAS -COMMAND -NAME 180 

(HAS-COMMAND-NAME-named-ob jl80  =  UNIX-LS-l-COMMANDO) 
(HAS-COMMAND-NAME-namel80  =  (SEQUENCE30  &))) 

(LS-l-FORMATO  (LS-l-FORMAT-stepO  =  (SEQUENCE30  &))) 


The  UNIX  domain  planner  produces  the  plan  of  using  the  Is  -1  command. 


UCEgo:  suggesting  the  plan: 

(PLANFOR74 

(goals74  =  (KNOW-gaO?  &)) 

(plan74  =  (TELL6  (effects  =  ( STATE -CHANGEl 

(final-statel  =  (KNOW-gaO?  &)))) 

(listener6-0  =  *USER*) 

(spea)cer6-0  =  UC) 


(propositione  =  {PLANFOR460  &))))) 
based  on  the  situation: 

(ANSWER-F0R4  <answer4  =  (PLANFOR460  &) ) 

(query4  =  (ACTION14?  &) ) ) 

(UC-HAS-GOAL66  &) 


Based  on  the  fact  that  PLANFOR460  (representing  using  the  Is  -1  command)  is  an  answer 
for  the  query  of  how  to  find  out  the  protection  of  a  file,  UCEgo  suggests  the  plan  of  tel¬ 
ling  the  user  the  answer  in  order  to  achieve  the  sub-goal  of  having  the  user  know  how  to 
find  out  the  protection  of  a  file. 


UCEgo  detects  the  following  concepts: 

(ANSWER-FOR4  &) 

(KNOW62  (knower62  =  *USER*) 

(fact62  =  (ACTION14?  &)) 

(truth-val62  =  FALSE) ) 

and  asserts  the  following  concept  into  the  database: 
(user-knov/s8  (uk-fact9  =  (PLAJ4FOR420  £)  ) 

(uk-user8  =  *USER*) 

(uk-truth-val8  =  FALSE) ) 

KNOME:  Asserting  *USER*  does  not  know  PLANFOR460 


Based  on  the  previous  inference  that  the  user  does  not  know  how  to  find  out  the  protec¬ 
tion  of  a  file  and  the  fact  that  using  Is  -1  is  a  plan  for  finding  that  out,  KNOME  infers  that 
the  user  does  not  know  that  Is  -1  is  a  plan  for  finding  out  the  protection  of  a  file  (the 
meaning  of  PLANFOR460). 


UCEgo  detects  the  following  concepts: 

(UC-HAS-GOAL66  &) 

(PLANFOR74  &) 

and  asserts  the  following  concept  into  the  database: 
(UC-HAS-INTENTIONIO  (intentionlO  =  (TELL6  &) ) 

(statuslO  =  ACTIVE) ) 


UC  adopts  the  intention  of  carrying  out  the  plan  of  telling  the  user  the  answer. 


UCEgo  detects  the  following  concepts: 
(UC-HAS-INTENTIONll  &) 

and  asserts  the  following  concept  into  the  database . 
(UCexpressS  (gen-prop3  =  (TELL6  &) ) ) 
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Telling  the  user  involves  passing  the  proposition  to  the  UCExpress  component,  which 
does  answer  expression.  UCExpress  is  described  in  Chapter  V. 


UCEgo  detects  the  following  concepts: 

{KNOW63  (k.nower63  =  *USER*) 

(fact63  =  (PLANFOR460  &) ) 

(truth-val63  =  FALSE) ) 

and  asserts  the  following  concept  into  the  database: 
(user-knows9  (uk-fact9  =  UNIX-LS-l-COMMANDO) 

(uk-user9  =  *USER*) 

(uk-truth-val9  =  FALSE) ) 

KNOME :  Asserting  *USER*  does  not  know  UNIX-LS-1  COMMANDO 
KNOME:  Since  UNIX-LS-l-COMMANDO  is  a  UNIX-LS-l-COMMAND, 
asserting  *USER*  does  not  know  UNIX-LS-l-COMMAND 
KNOME:  UNIX-LS-l-COMMAND  has  difficulty  MUNDANE,  SO  deducing: 
KNOME:  ruling  out  *USER*  =  EXPERT 

KNOME:  *USF.R*  is  SOMEWHAT-LIKELY  to  be  BEGINNER 

=>  likelihood (*USER*  =  BEGINNER)  =  SOMEWHAT -LIKELY 
KNOME-  *USER*  is  SOMEWHAT-UNLIKELY  to  be  INTERMEDIATE 

=>  likelihood {*USER*  =  INTERMEDIATE)  =  UNCERTAIN 


Since  the  user  does  not  know  the  main  usage  of  Is  -1  (the  meaning  of  ^ 

KNOME  can  infer  that  the  user  must  not  be  familiar  with  Is  -1.  Based  on  this,  KNOME 
makes  further  inferences  about  the  user’s  level  of  expenise.  Since  the  user  does  not 
know  Is  -1,  KNOME  infers  that  the  user  cannot  be  an  expert,  is  somewhat  unlikely  to  be 
an  intermediate,  and  is  somewhat  likely  to  be  a  beginner. 


Express:  now  expressing  the  PLANFOR: 

(PLANFOR460  &) 

Express:  expressing  a  complete  plan,  so  expanding  the  action 

PLANFOR460  into  its  subcomponents: 

TYPE-ACTIONO 


In  expressing  the  answer,  UCExpress  chooses  to  compress  the  infoimation  in  the  plan  of 
‘  ‘use  the  UNIX  Is  -1  command  which  has  the  format  of  Is  followed  by  -1  into  the  more 
succinct  subaction,  “type  ‘Is  -1’,’’  since  the  shorter  answer  is  easier  to  read  and  under¬ 
stand. 


Express : 


not  expressing  INFORMATION  EFFECTl?, 
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since  it  is  already  in  the  context. 


UCExpress  concludes  that  it  does  not  have  to  express  the  concept,  INFORMATION- 
EFFECTl,  which  represents  the  phrase  “find  out  the  protection  of  a  file,  since  this  is 
already  part  of  the  context  of  the  dialog. 


The  generator  is  passed: 
(TELL6  &) 


c 


The  actual  translation  of  concepts  into  English  is  done  by  the  tactical  level  generator 
component  of  UC. 


Type  'la  -1'  . 


The  next  query  illustrates  how  UC  corrects  user  misconceptions. 


#  What  does  Is  -p  do? 

The  parser  produces: 

(ASKll  (listenerll  =  UC) 

(spea)cerll  =  *USER*) 

(asked-forll  =  (QUESTIONll  (what-isll  =  STATE13?)))) 
(HAS-EFFECT21?  (ef  fect-of-coinmand21  =  STATE13?) 

(conmand-of-effect21  =  UNIX-LS-COMMANDO) ) 
(HAS-OPTION3  (option3  =  -p-OPTIONO) 

(command-of-option3  =  UNIX-LS-COMMANDO)) 


The  parser/understander  interprets  the  user’s  question  as  a  query  about  the  effects 
(STATE13)  of  UNIX-LS-COMMANDO  which  has  a  -p  option. 


c 


The  processing  up  to  this  point  is  similar  to  the  previous  example:  the  goal  analysis 
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component  infers  that  the  user’s  goal  is  to  know  the  effects  of  Is  -p,  and  UCEgo  adopts 
the  user’s  goal  of  knowing  as  a  sub-goal  of  helping  the  user  (UC-HAS-GOAL67). 


UCEgo  detects  the  following  concepts: 

(HAS-EFFECT21?  &) 

(UC-HAS-GOAL67  &) 

and  asserts  the  following  concept  into  the  database: 
(UC-f ind-ef fectsl  (unknown-commandl  =  UNIX-LS-COMMANDO) ) 


UC-find-effects  is  a  procedure  which  finds  the  effects  of  UNIX  commands. 


UCEgo:  trying  to  find  effects  for  UNIX-LS  COMMANDO 

UCEgo:  unknown  relation; 

(HAS-OPTION3  &) 

UCEgo:  User  has  the  misconception: 

(HAS-MISCONCEPTIONl  (confusedl  =  *USER*) 

(misconception!  =  (KAS-OPTION3  &))) 

since 

(KNOW42  (fact42  =  (ALL3  (such-that3  = 

(HAS-OPTIONO?  (optionO  =  (ALL3  &)) 
(command-of-optionO  = 
SIMPLE-COMMANDO?) ) ) 
(all-type3  =  OPTIONO?))) 

(knower42  =  UC) ) 
and  since  the  user  believes; 

(HAS-OPTION3  (option3  =  -p-OPTIONO) 

(command-of-option3  =  UNIX-LS-COMMANDO)) 
which  involves  an  unknown  OPTION 


In  the  process  of  finding  the  effects  of  the  UNIX-LS-COMMANDO,  UCEgo  notices  that 
it  has  an  option  (HAS-OPTION3)  which  does  not  have  a  analog  in  UC’s  knowledge  base. 
This  in  conjunction  with  the  fact  that  UC  knows  all  of  the  options  of  simple  commands 
(of  which  Is  is  a  member),  tells  UC  that  the  user  has  a  misconception.  What  UC  knows  is 
represented  by  KNOME  using  meta-knowledge ,  such  as  the  above  fact  to  model  the  limi¬ 
tations  of  UC’s  own  knowledge.  Meta-knowledge  is  described  in  Chapter  II,  Section  4. 
Correcting  user  misconceptions  is  described  in  Chapter  HI,  Section  4. 


UCEgo;  suggesting  the  plan: 

(PLANFOR76 

(goals76  =  (HELPS  &)  ) 

(plan76  = 

(SATISFY8  (needs  = 

(KNOW67?  (knower67  =  *USER*) 
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(f act 67 

(actorB  =  UC) ) ) ) 
based,  on  the  situation; 
(UC-HAS-GOAL63  &) 
(HAS-MISCONCEPTIONl  &) 


(NEGATE 1  (negativel  = 

(HAS-OPTION3  &)))))) 


To  satisfy  the  goal  of  helping  the  user,  UCEgo  suggests  the  plan  of  having  the  user  know 
that  Is  does  not  have  a  -p  option. 


The  processing  here  follows  the  same  pattern  as  in  the  previous  example:  UCEgo  adopts 
the  intention  of  carrying  out  the  plan,  passes  the  proposition  to  UCExpress  which  pa^scb 
the  concepts  to  the  tactical  generator. 


Is  does  not  have  a  -p  option. 


UC’s  response  to  the  next  user  question  shows  how  UCExpress  uses  an  example  format 
to  more  clearly  express  information  to  the  user. 


#  How  can  J  add  write  permission  to  a  file? 

The  parser  produces: 

(ASK12 

(listenerl2  =  UC) 

(speakerl2  =  *USER*) 

^^^QUESTIOT12  (what-isl2  =  (ACTI0N15?  (actorlS  =  *USER*)))))) 

(CHANGE-PROT-FILE-ACTIONO? 

(ch-prot-effectO  =  (CHANGE-PROT-FILE-EFFECTO? 

(change-protO  =  FILE-PROTECTION2) 
(change-f ileO  =  FILES?))) 

(actorO-2  =  *USER*) 

(causeO-1  =  (ACTIONIS?  &))))) 

(HAS-PROT-VALUEl  (value-protection-typel  =  ADD-STATUS) 
(prot-type-argl-0  =  FILE-PROTECTION2) ) 

(HAS-FILE-PROTECTION2  (prot-file2  =  FILES?) 

(file-prot2  =  FILE-PROTECTION2) ) 
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(HAS-ACCESS-TYPEl  (access-protection-typel  -  WRITE-PROT) 

(prot-type-argl  =  FILE-PROTECTION2) ) 

UCEgo  detects  the  following  concepts: 

FILE-PROTECTION2 

and  asserts  the  following  concept  into  the  database: 

{ user~knows 1 1  (uk— factll  —  FILE~PR0TECTI0N2 ) 

(uk-userll  =  *USER*) 

(uk-truth-valll  =  TRUE) ) 

KNOME :  Asserting  *USER*  knows  FILE-PROTECTION2 
KNOME:  FILE-PROTECTION2  is  a  FILE-PROTECTION,  but  KNOME 
already  knows  that  *USER*  knows  FILE-PROTECTION, 
so  not  making  any  more  deductions . 


KNOME  already  inferred  from  the  user’s  first  query  that  the  user  knows  the  concept  of 
FILE-PROTECnON,  so  KNOME  does  not  make  any  additional  inferences  about  the 
user’s  level  of  expertise  this  time. 


The  processing  here  is  standard:  the  goal  analyzer  determines  that  the  user  wants  to  know 
how  to  add  write  permission  to  a  file,  the  domain  planner  is  called  and  returns  with  the 
plan  of  using  the  chmod  command,  and  UCEgo  implements  the  plan  of  telling  the  user 

this  information. 


KNOME:  Asserting  *USER*  does  not  know  UNIX-CHMOD-COMMANDO 
KNOME:  Since  UNIX-CHMOD-COMMANDO  is  a  UNIX-CHMOD-COMMAND, 
asserting  *USER*  does  not  know  UNIX-CHMOD-COMMAND 
KNOME:  UNIX-CHMOD-COMMAND  has  difficulty  COMPLEX,  so  deducing: 
KNOME:  *USER*  is  LIKELY  to  be  BEGINNER 

=>  likelihood (*USER*  =  BEGINNER)  =  VERY-LIKELY 
KNOME:  *USER*  is  SOMEWHAT-LIKELY  to  be  INTERMEDIATE 

=>  liJcslihood  ( *USER*  =  INTERMEDIATE)  —  SOMEWHAT  — LIKEuY 


Based  on  the  fact  that  the  user  does  not  know  how  to  add  write  permission  to  a  file,  and 
hence  does  not  know  that  the  UNIX  chmod  command  is  a  plan  for  doing  this,  KNOME 
can  infer  that  the  user  is  not  familiar  with  the  chmod  command.  This  aUows  KNOME  to 
infer  that  the  user  is  likely  to  be  a  beginner  and  somewhat  likely  to  be  an  intermediate. 
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Express:  now  expressing  the  PLANFOR: 

(PLANFOR330  &) 

Express:  creating  an  example  for  the  incomplete  plan,  CHMOD-FORMATO 

Express:  choosing  a  name,  foo,  for  an  example  file. 

Express:  selecting  USER-PROT  —  print  name,  u, 

to  fill  in  a  parameter  of  the  example. 


UCExpress  is  passed  PLANFOR330  to  express.  PLANFOR330  is  an  incomplete  plan, 
because  the  user  did  not  specify  either  the  user  type  (either  user,  group,  or  other)  to 
which  chmod  should  add  write  permission  or  the  name  of  the  file  argument.  By  consult¬ 
ing  KNOME,  UCExpress  can  infer  that  the  user  does  not  know  the  command  format  of 
chmod.  In  order  to  communicate  the  format  to  the  user,  UCExpress  uses  an  example.  In 
order  to  create  an  example,  UCExpress  must  fill  in  the  unspecified  parts  of  the  plan  by 
choosing  a  name  for  the  file  and  a  user  type  for  the  protection.  When  and  how  to  use 
specialized  formats  such  as  examples  to  inform  the  user  is  described  in  Chapter  V,  Sec¬ 
tion  3. 


Express:  created  the  example (s) : 

( (TELLIO 

(speakerlO-0  =  UC) 

(listenerlO-0  =  *USER*) 

(propositionlO  = 

(EXAMPLEO 

(exampleO  =  (PLANFOR330-0 
(goals330-0  = 

(CHANGE-PROT-FILE-EFFECTO-0?  . . . ) ) 

(plan330-0  =  (TYPE-ACTIONl 

(speak.erl-4  =  *USER*) 
(type-stringi  = 

(CHMOD-FORMATO -0  ...)))))))))) 

Express:  not  expressing  CHANGE-PROT-FILE-EFFECTO?, 

since  it  is  already  in  the  context. 


This  concept  corresponds  to  the  phrase  “add  write  permission  to  a  file.”  Since  UCEx¬ 
press  has  pruned  this  concept  (i.  e.  marked  the  concept  as  not  needing  generation),  the 
tactical  generator,  upon  checking  that  this  concept  is  unambiguous  (i.  e.  there  are  not 
other  EFFECTS  being  generated),  is  able  to  omit  the  concept.  This  shortens  “To  add 
write  permission  to  a  file,  use  chmod”  to  just  “Use  chmod.”  Pruning  by  UCExpress  is 
described  in  Chapter  V,  Section  2. 
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The  generator  is  passed: 

(TELL9  &) 

The  generator  is  passed: 

(TELLIO  4) 

Use  chmod. 

For  exaiqsle,  to  add  individual  write  permission  to  the  file  named 
foo,  type  'chmod  u+w  foo' . 


In  the  next  example,  UCEgo  takes  the  initiative  in  the  conversion  to  volunteer  informa¬ 
tion  to  the  user. 


#  Is  chin  logged  into  the  network? 

The  parser  produces: 

{ASK13  (asked-forl3  = 

(QUESTION13 
(what-isl3  = 

(STATE-OF-USERO? 

(user-stateO  =  (LOGGED -INTO -NETWORK 1 

(onto-networkl  =  NETWORK2) ) ) 
(state-userO  =  USERS) ) ) ) ) 

(listenerl3  =  UC) 

(speakerl3  =  *USER*)) 

(HAS -USER-NAME 2  (user-name2  =  chin)  (named-user2  =  USERS) ) 


KNOME:  Asserting  *USER*  does  not  know  STATE-OF-USERO? 


UCEgo  detects  the  following  concepts: 

(UC-HAS-GOAL70  &) 

and  asserts  the  following  concept  into  the  database: 
(UC-is-statel  (is-statel  =  (STATE-OF-USERO?  &) ) ) 


UC-is-state  is  a  procedure  for  determining  state  information  for  users.  Since  access  to 
UNIX  was  not  implemented  for  this  version  of  UC,  UC-is-state  always  claims  that  UC 
does  not  know  the  information. 
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UCEgo :  UC  does  not  know  STATE-OF-USERO? 

UCEgo:  detected  the  goal: 

(UC-HAS-GOAL71  {goal71  =  (KNOW75?  (knower75  =  UC) 

(fact75  =  (STATE-OF-USERO?  &))))) 

from  the  situation: 

(KNOW74  (knower74  =  UC) 

{truth-val74  =  FALSE) 

(fact74  =  (STATE-OF-USERO?  &))) 

(UC-HAS-GOAL70  &) 


Since  UC  has  the  goal  of  having  the  user  know  STATE-OF-USERO,  and  UC  does  not 
know  this  information,  UCEgo  adopts  the  meta-goal  of  UC  knowing  this  information. 
Meta-goals  are  described  in  Chapter  HI,  Section  3. 


UCEgo  detects  the  following  concepts: 

(UC-HAS-GOAL71  &) 

and  asserts  the  following  concept  into  the  database: 
(UC-is-state2  (is-state2  =  (STATE-OF-USERO?  &))) 


UC-is-state  is  called  whenever  UC  has  the  goal  of  knowing  state  information  for  a  user. 
Previously  UC-is-state  was  called,  since  UC  had  the  goal  of  having  the  user  know.  Now 
UC  has  the  goal  of  having  UC  know,  so  UC-is-state  is  called  again. 


UCEgo:  suggesting  the  plan: 

(PLANFOR81  (planSl  =  (APOLOGIZE2  (apologyZ  =  (KNOW74  &) ) 

(listener2-3  =  *USER*) 
(speaker2-3  =  UC) ) ) 

(goalsSl  =  (BE-POLITE5  (polite-to5  =  *USER*) 

(is-polite5  =  UC) ) ) ) 

based  on  the  situation: 

(KNOW? 4  &) 

(HAS-GOAL-ga3  &) 

(UC-HAS-GOAL61  (status61  =  ACTIVE)  (goal61  =  (BE-POLITE5  &))) 


Since  UC  does  not  know  what  the  user  wants  to  know,  and  UC  wants  to  be  polite  to  the 
user,  UCEgo  suggests  the  plan  of  apologizing  to  the  user  for  not  knowing. 


UCEgo  detects  the  following  concepts: 
(UC-HAS-GOAL61  &) 

(PLANFOR81  &) 
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and  asserts  the  following  concept  into  the  database 
(UC-HAS-INTENTI0N17  (intentionl7  =  (APOLOGIZE2  &) ) 

(Statusl7  =  ACTIVE) ) 

UCEgo  detects  the  following  concepts . 
(UC-HAS-INTENTION17  &) 

and  asserts  the  following  concept  into  the  database 
(UCexpressG  (gen-prop6  =  (APOLOGIZE2  &))) 

Express:  not  expressing  STATE-OF-USERO?, 

since  it  is  already  in  the  context. 

The  generator  is  passed: 

(APOLOGIZE2  &) 

I'm  sorry,  I  do  not  Icnow  that. 


Since  UCExpress  marked  STATE-OF-USERO  as  not  needing 

generator  is  able  to  consider  using  the  pronoun  “that  in  place  of 

Since  UCExpress  has  not  actually  altered  the  conceptual  network,  but  only  marked 

STATE-OF-USERO  as  not  needing  generation,  the  generator  still  has  enough  iniormauon 

to  generate  the  full  sentence,  if  the  use  of  a  pronoun  were  to  be  ambiguous. 

At  this  point,  UC  still  has  the  goal  of  knowing  whether  chin  is 
although  UCEgo  does  not  know  of  any  plans  for  achieving  this  goal.  So  UCE^adop 
die  meta-goal  (shown  below)  of  finding  out  a  plan  for  achieving  this  goal  This  will 
eventually  lead  UC  to  find  a  plan  for  finding  out  whether  chin  is  logged  into  the  network 
and  then  to  volunteer  this  information  to  the  user. 


UCEgo;  do  not  know  a  single  planfor  the  foreground  goal: 

(UC-HAS-G0AL71  &) 
so  adding  the  meta-goal; 

(UC-HAS-GOAL72  (goal72  =  (KNOW76?  (knower76  =  UC) 

(UC  HAS  vy  (fact76  =  ACTIONl 6? )  )  )  ) 

(PLANFOR82?  (goals82  =  ( INFORMATION-EFFECT2? 

‘  (desired-info2  =  (STATE-OF-USERO?  &)) 

(informant2  =  UC) ) ) 

(plan82  =  ACTION16?) ) 

UCEgo  detects  the  following  concepts. 

(PLANFOR82?  &) 

(UC-HAS-GOAL72  &)  ,  v. 

and  asserts  the  following  concept  into  the  database: 
*™ir4lanner4  ,u«r-go.la4  -  , INrORMATION-ErFECT27  4,)) 


UCEgo  calls  the  domain  planner  to  produce  a  plan  for  achieving  UC  s  goal. 


t 
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The  planner  is  passed; 

( (INFORMAT I0N-EFFECT2?  &)) 

The  planner  produces :  „  .  . 

(PLANFOR490  (goals490  =  ( INFORMAT ION-EFFECT2?  &))  nrM  n 

(plan490  =  (UNIX-RWHO-COMMANDO  (rwho-actorO  -  UC) ) ) ) 

(RWHO-HAS -FORMAT 0 

(RWHO-HAS-FORMAT-COmmandO  =  (UNIX-RWHO-COMMANDO  &)) 
(RWHO-HAS-FORMAT-formatO  = 

(RWHO-FORMATO  (RWHO-FORMAT-StepO  =  rwho) ) ) ) 

(HAS-EFFECT180 

(command-of-effectl80  =  (UNIX-RWHO-COMMANDO  &) ) 

(ef f ect-of-commandl8 0  =  (LIST-ACTIONllO 

(list-lOCllO  =  TERMINALS) 

(list— ob jsllO  =  USER— LOGIN-TIMEl? ) ) ) ) 

(HAS-COMMAND-NAME200 

(HAS-COMMAND-NAME-named-ob j200  =  (UNIX-RWHO-COMMAND 
(HAS-COMMAND-NAME-name200  =  rwho) ) 


The  domain  planner  returns  the  plan  of  using  the  rwho  command  to  find  out  if  chin  is 
logged  into  the  network. 


UCEgo  detects  the  following  concepts: 

(UC- HAS -GOAL 6 6  &) 

(PLANFOR450  &) 

and  asserts  the  following  concept  into  the  database: 
(UC-HAS-INTENTION21  (intention21  =  (UNIX-RWHO-COMMANDO  &)) 

(status21  =  ACTIVE) ) 


UCEgo  would  like  to  carry  out  the  plan  of  using  the  rwho  command,  but  cannot,  since 
UC  does  not  presently  have  a  UNIX  interface. 


UCEgo:  suggesting  the  plan; 

(PLANFOR84 

(goals84  =  (HELPS  &) ) 

, planes  -  tSATISPYie  ,fact69  -  ,PL«.roR4eO  s,, 

(lcnower69  =  *USER*)  )  )  )  )  ) 

based  on  the  situation: 

(UC-HAS-GOAL63  &) 

(PLANFOR490  &) 

(HAS-GOAL-ga3  &) 
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Based  on  the  fact  that  UC  wants  to  help  the  user  (UC-HAS-GOAL63),  Ae  user  ™ts  to 
know  something  (HAS-GOAL-ga3),  there  is  a  plan  for  finding  ±is  out 
and  the  user  does  not  know  the  plan  (not  shown),  UC  suggests  that  a  plan  (PLANFOR84) 
for  helping  the  user  is  for  UC  to  let  the  user  know  the  plan.  This  is  an  example  of  when 
UCEgo  decides  to  volunteer  information  to  the  user.  The  user  did  not  specific^ly  as 
UC  how  to  find  out  if  chin  is  logged  into  the  network;  rather  the  user  only  asked  UC 
whether  chin  is  logged  into  the  network.  UCEgo  takes  this  opportunity  to  teach  the  user 
something  helpful.  Note  that  UCEgo  only  decides  to  volunteer  ^his  mformanon  if  it 
believes  that  the  user  does  not  already  know  the  information  (as  modeled  by  IWOME). 
Different  situations  in  which  a  system  might  want  to  volunteer  information  are  described 

in  Chapter  Ill,  Section  5. 


To  find  out,  type  'rwho' . 


This  followup  query  by  the  user  shows  the  use  of  a  simile  format  by 

simile  format  takes  advantage  of  the  user’s  prior  knowledge  as  modeled  by  KNOME  in 

order  to  convey  information  to  the  user  more  succinctly. 


#  What  exactly  does  rwho  do? 

The  parser  produces: 

(ASK14  (listenerl4  =  UC) 

(spea)cerl4  =  *USER*) 

(as)ced-forl4  =  (QUESTION14  (what-isl4  =  STATE14?)))) 
(HAS-EFFECT22?  (ef  f  ect-of-conimand22  =  STATE14?) 

(command-of-effect22  =  UNIX-RWHO-COMMANDl) ) 


UCEgo:  trying  to  find  effects  for  UNIX-RWHO-COMMANDl 

the  effects  are: 

{ (HAS-EFFECT16-0 

(coiranand-of-effectl6-0  =  (UNIX-RWHO-COMMANDl  &) ) 
(ef fect-of-corranandl6-0  = 

(LIST-ACTION9-0 

(list-loc9-0  =  TERMINAL3-0) 

(list-ob js9-0  = 

(ALL8-0  (such-that8-0  = 
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( LOGGED - INTO-NETWORKO - 0  ? 
(network-userO-0  = 

{ALL8-0  i)) 

(via-loginO-0  = 

{LOGGED-INTO-MACHINE7-0? 

(Iogged-on-user7-0  =  (ALL8-0  &)) 
(login-ttY7-0  =  TTY5-0?) ) ) 
(onto-networkO-0  =  NETWORKl-0) ) ) 
{all-type8-0  =  USER8-0?) ) ) ) ) ) 

(HAS-EFFECT17-0  _ 

(conmand-of-effectl7-0  =  (UNIX-RWHO-COMMANDl  &) ) 

(ef fect-of-commandl7-0  = 

(LIST-ACTIONIO-O  ( list-loclO-0  =  TERMINAL3-0) 
(list-objslO-0  =  TTY5-0?)))) 


(HAS-EFFECT18-0 

(coinmand-of-effectl8-0  =  (UNIX-RWHO-COMMANDl  &)  ) 

(ef  fect-of-conimandl8-0  = 

(LIST-ACTIONll-0  (list-objsll-0  =  USER-LOGIN-TIMEl 
(list-locll-0  =  TERMINAL3-0) ) ) ) ) 


0?) 


UCExpress:  Found  a  related  command,  so  creating  a  comparison 
between  UNIX-RWHO-COMMANDl  and  UNIX-WHO-COMMANDO 


L 


[n  describing  the  effects  of  a  command,  UCExpress  checks  to  see  if  there  is  a  rented 
tommand  in  the  command  hierarchy  which  the  user  already  knows  (as  modeled  y 
KNOME)  and  which  can  be  used  to  form  a  comparison  with  the  comm^d  atom  whic 
the  user  asked.  If  resultant  simile  is  more  succinct  than  simply  listing  the  effects  of  the 
command  directly,  then  UCExpress  uses  the  simile  to  convey  the  knowledge  to  the  user. 
Similes  and  other  explanatory  formats  are  described  in  Chapter  V,  Section  3. 


KNOME:  Asserting  *USER*  does  not  know  HAS-EFFECT26 


KNOME: 

KNOME: 

KNOME: 
KNOME : 


Asserting  *USER*  does  not  know  UNIX-RWHO-COMMANDl 
Since  UNIX-RWHO-COMMANDl  is  a  UNIX-RWHO-COMMAND , 
asserting  *USER*  does  not  know  UNIX-RWHO-COMMAND 
UNIX-RWHO-COMMAND  has  difficulty  MUNDANE,  SO  deducing: 
asserting  *USER*  =  BEGINNER 


The  fact  that  the  user  does  not  know  the  rwho  command,  in  conjunction  with  previous 
facts,  allows  UC  to  infer  that  the  user  is  a  beginner. 


w 


-26- 


irwho  is  like  who. 


except  rwho  is  for  all  users  on  the  network. 


The  last  example,  below,  shows  UC  refusing  to  help  the  user  delete  someone  else’s  files 


#  How  can  I  delete  Chin's  files? 


The  parser  produces; 

(ASK15 

(listenerlS  =  UC) 

(speakerl5  =  *USER*) 
(asked-forl5  =  (QUESTION15 
(what-islS 


(ACTION17?  (actorl7  =  *USER*)))))) 


(DELETE-ACTIONO? 

(del-effecto  =  (DELETE-EFFECTO? 

/r\C»T  r’rnc'— C'tTTTTpT'-.-P-?  nal  —  StStSO  “ 

^  J_l  i-J*-  *-  *-»'*-'*  — 

(EXISTSO  (exist-objectO  =  FILE6) 
(existenceO  =  FALSE) ) ) 
(DELETE-EFFECT-initial-stateO  = 

(EXISTS3  (exist-ob ject3  =  FILE6) 
(existence3  =  TRUE) ) ) 
(del-objectO  =  FILES) ) ) 


(actorO-3 

(causeO-2 

(HAS-OWNERl 

(HAS-NAME27 


=  *USER*) 

=  (ACTION17?  &))))) 

(ownerl  =  PERSON39)  (owned-objl  =  FILES)) 
(name27  =  chin)  {named-obj27  =  PERSON39) ) 


UCEgo:  suggesting  the  plan: 

{PLANFOR89  (goals89  =  (HELPS  &)) 

(plan89  =  (SATISFY14  {needl4  =  (KNOW-gaS?  &)) 

(actorl4-l  =  UC) ) ) ) 

based  on  the  situation: 

(UC-HAS-GOALS3  &) 

(HAS-GOAL-gaS  &) 


As  in  normal  situations,  UCEgo  suggests  the  plan  of  having  the  user  know  how  to  delete 
Chin’s  files  in  order  to  help  the  user. 


UCEgo:  suggesting  the  plan: 

(PLANFOR90 

(goal390  =  (ACT-ETHICALLYO  (actorO-0  =  UC) ) ) 
(plan90  =  (SATISFY15  (actorlS  =  UC) 

(needlS  =  (PREVENTS 


(preventers  =  UC) 
(prevent-stateS  = 

(KNOW-gaS?  &))))))) 


based  on  the  situation: 

(HAS-OWNERl  &) 

(UC-HAS-GOAL62  (status62  =  ACTIVE)  (goal62 
(PLANFOR-ga8  (goals-ga8  =  (DELETE-EFFECTO? 

(plan-ga8  =  (ACTION17?  &) ) ) 
(HAS-GOAL-gaS  &) 


=  (ACT-ETHICALLYO  &))) 
&)  ) 


However,  in  this  particular  situation  (in  which  someone  wants  to  know  how  to  delete  a 
file  owned  by  someone  else  and  UC  has  the  goal  of  acting  educaUy),  LCEgo  suggests  ^  .e 
plan  of  preventing  the  user  from  knowing  how  in  order  to  act  ethically. 


UCEgo  detects  the  following  concepts: 

(UC-HAS-GOAL62  &) 

(PLANFOR90  &) 

and  asserts  the  following  concept  into  the  database 
(UC-HAS-INTENT10N23  (intention23  =  (SATISFYIS  &)) 

(status23  =  ACTIVE)) 

UCEgo  detects  the  following  concepts: 

(UC-HAS-GOAL63  &) 

(PLANFOR89  &) 

and  asserts  the  following  concept  into  the  database 
(UC-HAS-INTENTION24  (intention24  =  (SATISFY14  &)) 

(status24  =  ACTIVE) ) 


UCEgo  adopts  the  intention  of  carrying  out  the  two  plans. 


UCEgo:  detected  the  goal: 

(UC-HAS-GOAL75  (goal75  =  (KNOW-ga5?  &))) 
from  the  situation: 

(UC-HAS-INTENTION24  &) 


UCEgo:  detected  the  goal: 

(UC-HAS-GOAL76  (goal76  =  (PREVENTS  &))) 
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from  the  situation: 
(UC-HAS-INTENTION23  &) 


UCEgo  adopts  as  sub-goals;  the  goal  of  having  the  user  know,  and  the  goal  of  preventing 
the  user  from  knowing. 


UCEgo  detects  the  following  concepts: 

(PLANF0R-ga8  &) 

(UC-HAS-G0AL75  &) 

and  asserts  the  following  concept  into  the  database: 
(UNIX-planner5  (user-goals5  =  (DELETE-EFFECTO?  &))) 

UCEgo  detects  the  following  concepts: 

(UC-HAS-GOAL75  &) 

(UC-HAS-GOAL76  &) 

and  asserts  the  following  concept  into  the  database: 
(HAS-PRECEDENCE7 

(greater7  =  (UC-HAS-GOAL71 
(goal71  = 

(RESOLVE-GOAL-CONFLICT2 

(conf lict-goal-A2  =  (UC-HAS-GOAL7 6  &) ) 
(conflict-goal-B2  =  (UC-HAS-GOAL75  &)))))) 
(lesser7  =  (UC-HAS-GOAL76  &) ) ) 


Since  UC  both  wants  something  and  wants  to  prevent  it,  UCEgo  detects  a  goal  conflict. 
So  it  adopts  the  meta-goal  (UC-HAS-GOAL71)  of  resolving  the  conflict  (RESOLVE- 
GOAL-CONFLICT2).  The  HAS-PRECEDENCE7  relation  states  that  the  goal  of  resolv¬ 
ing  the  conflict  should  take  precedence  over  one  of  the  conflicting  goals.  The  HAS- 
PRECEDENCE8  relation  below  states  that  resolving  the  conflict  also  has  precedence 
over  the  other  conflicting  goal. 


UCEgo  detects  the  following  concepts: 

(UC-HAS-GOAL75  &) 

(UC-HAS-GOAL76  &) 

and  asserts  the  following  concept  into  the  database. 
(HAS -PRECEDENCE 8  (lesserS  =  (UC-HAS-G0AL75  &) ) 

(greater 8  =  (UC-HAS-G0AL7 1  &) ) ) 

UCEgo:  detected  the  goal: 

(UC-HAS-GOAL77  &) 
from  the  situation: 

(UC-HAS-GOAL75  &) 

(UC-HAS-GOAL76  &) 


UCEgo:  suggesting  the  plan: 
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(PLANF0R91  (goalsSl  =  (RESOLVE-GOAL-CONFLICT2  &) ) 
(plan91  =  (UC-resolve-conflictl 

(goal-Al  =  (UC-HAS-G0AL7 6  &)) 
(goal-Bl  =  {UC-HAS-GOAL75  &))))) 

based  on  the  situation: 

(UC-HAS-GOAL77  &) 


UC-resolve-conflict  is  a  procedure  which  tries  to  resolve  the  goal  conflict. 


UCEgo :  suggesting  the  plan: 

(PLANFOR92 

(plan92  =  (APOLOGIZES 

(speaker3-3  =  UC) 

(apology3  = 

(HAS-ABILITYl  (ability!  = 

(TELL15  (speakerl5-0  =  UC) 

(listenerl5-0  =  *USER*) ) ) 
(truth-vall-1  =  FALSE) 

(doerl  =  UC) ) ) 

(listener3-3  =  *USER*) ) ) 

(goals92  =  (BE-POLITE5  &))) 
based  on  the  situation: 

(ASK15  &) 

(UC-HAS-G0AL61  &) 

(UC-HAS-GOAL76  &) 


Since  UC  does  not  want  the  user  to  know  something  which  the  user  asked  about 
still  wants  to  be  polite  to  the  user.  UCEgo  suggests  the  plan  of  apologizing  to  the 
not  be  able  to  tell  the  user. 


UCEgo  detects  the  following  concepts: 

(UC-HAS-GOAL61  &) 

(PLANFOR92  &) 

and  asserts  the  following  concept  into  the  database: 
(UC-HAS-INTENTION25  (intention25  =  (APOLOGIZES  &)) 

(status25  =  ACTIVE) ) 

UCEgo  detects  the  following  concepts. 

(UC-HAS-GOAL71  &) 

(PLANF0R91  &) 

and  asserts  the  following  concept  into  the  database:^ 
(UC-HAS-INTENTION26  (intention26  -  (UC-resolve-conf liv-t 

(status26  =  ACTIVE)) 

UCEgo  detects  the  following  concepts. 


,  yet  UC 
;  user  for 


-30- 


(UC-HAS-INTENTION25  &) 

and  asserts  the  following  concept  into  the  database; 

(UCexpresslO  (gen-proplO  =  (APOLOGIZES  &) ) ) 

UCEgo  detects  the  following  concepts: 

(UC-HAS- INTENTIONS  6  &) 

and  asserts  the  following  concept  into  the  database: 
(UC-resolve-conf lictl  &) 

UCEgo:  detected  conflicting  goals: 

(UC- HAS -GOAL 7 6 
(goal76  = 

(PREVENTS  (preventers  =  UC) 

(prevent-stateS  = 

(KNOW-gaS?  (k.nower-gaS  =  *USER*) 

(fact-gaS  =  (ACTION17? 

(actorl7  =  *USER*) ))))))) 

(UC-HAS-GOAL7S 
(goal7S  = 

(KNOW-gaS?  (knower-gaS  =  *USER*) 

(fact-gaS  =  (ACTION17?  (actorlS  =  *USER*) ) ) ) ) ) 

UCEgo:  goal,  UC-HAS-GOAL76,  has  higher  precedence, 

so  resolving  goal  conflict  by  discarding  the  goal,  UC-HAS-GOAL7S 


The  goal  conflict  is  finally  resolved  by  abandoning  one  of  the  conflicting  goals.  Resolv¬ 
ing  goal  conflicts  is  described  in  Chapter  IV,  Section  2.5. 


The  planner  is  passed: 

( (DELETE-EFFECTO?  &)) 

The  planner  produces: 

(PLANFOR2SO 

(goalsSSO  =  (DELETE-EFFECTO?  &)) 

(planSSO  =  (UNIX-RM-COMMANDO  (rm-fileO  =  FILES) 

(UNIX-RM-COMMAND-effectO  = 
(DELETE-EFFECTO?  &))))) 
(HAS-FILE-NAME20  (named-f ile20  =  FILES) 

(file-name20  =  (lisp=  nil))) 

(RM-HAS -FORMAT 0 

(RM-HAS-FORMAT-COmmandO  =  (UNIX-RM-COMMANDO  &)) 
(RM-HAS-FORMAT-formatO  = 

(RM-FORMATO  ( rm-f ile-argO  = 

(file-name20  =  aspectual-of 

(HAS-FILE-NAME20  &))) 
(RM-FORMAT-stepO  =  rm) ) ) ) 

( HAS -COMMAND -NAME  0  0 

(HAS-COMMAND-NAME-named-ob jOO  =  (UNIX-RM-COMMANDO  &) ) 
(HAS-COMMAND-NAME-nameOO  =  rm) ) 


UCEgo  detects  the  following  concepts; 

(ANSWER-FOR9  (answer9  =  (PLANFOR250  &) ) 

(KNOW83  (knower83  =  *USER*) 

(fact83  =  (ACTI0N17?  &) ) 

(truth-val83  =  FALSE) ) 

and  asserts  the  following  concept  into  the  database: 
(user-knows20  (uk-fact20  =  (PLANFOR250  &) ) 

(uk-user20  =  *USER*) 

(uk— truth— val20  =  FALSE) ) 


<query9  =  (ACTION17?  &) ) ) 


KNOME 


:  Asserting  *USER*  does  not  know  PLANFOR250 


UCEgo  detects  the  following  concepts: 

(KNOW84  (knower84  =  *USER*) 

(fact84  =  (PLANFOR250  &) ) 

(truth-val84  =  FALSE) ) 

and  asserts  the  following  concept  into  the  database: 
{user-knows21  (uk-fact21  =  (UNIX-RM-COMMANDO  &) ) 

(uk-user21  =  *USER*) 

(uk-truth-val21  =  FALSE) ) 

KNOME:  Asserting  *USER*  does  not  know  UNIX-RM-COMMANDO 
KNOME:  Since  UNIX-RM-COMMANDO  is  a  UNIX-RM-COM>UVND, 

asserting  *USER*  does  not  know  Ui'JIX-RI'i-COMI-lAl'TO 

The  generator  is  passed: 

(APOLOGIZES  &) 

I'm  sorry,  I  cannot  tell  you. 

UCEgo:  do  not  know  a  single  planfor  the  foreground  goal: 
(UC-HAS-GOAL76  &) 

SO  adding  the  meta-goal: 

(UC-HAS-GOAL78  (goal78  =  (KNOW87?  (knower87  =  UC) 

(fact87  =  ACTION18?) ) ) ) 

{PLANFOR93?  (goals93  =  (PREVENTS  &) )  (plan93  =  ACTION18?) ) 


Since  UCEgo  does  not  know  how  to  prevent  the  user  from  knowing  how  to  delete  Chin  s 
files,  it  adopts  the  meta-goal  of  finding  out  a  plan  for  achieving  that  goal. 


UCEgo  detects  the  following  concepts: 

(PLANFOR93?  &) 

(UC-HAS-GOAL78  &) 

and  asserts  the  following  concept  into  the  database 
(UNIX-planner6  (user-goals6  =  (PREVENTS  &) ) ) 

The  planner  is  passed: 

( (PREVENTS  &) ) 


The  planner  produces; 
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nil 


The  domain  planner  does  not  know  of  any  plans  either. 


#  Good-bye 


Good-bye . 


3.2.  Other  Approaches  to  Building  Natural  Language  Consultants 


At  about  the  same  time  as  UC,  The  UCC  system  ([Douglass  and  Hegner,J982]) 
was  built  to  answer  questions  about  UNDC.  UCC  stored  information  about  UNia  m  a 
conventional  data-base,  and  translated  user  queries  into  a  data-base  query  l^guage, 
which  was  then  used  to  retrieve  information  about  UNDC  from  the  data-base.  This  work 
was  continued  in  the  Yucca-II  system  ([Hegner,  1988]  and  [McKevitt  and  Wife,  1987]. 
Yucca-II  is  also  designed  as  a  data-base  of  UNDC  facts  with  a  separate  natural  language 

front  end. 

More  recently,  the  AQUA  system  ([Quilici  et  al.,  1985],  [Quilici  et  al.,  1986],  and 
[Quilici  et  al.,  1987])  uses  the  paradigm  of  reminding  to  recognize  user  problems  as 
being  similar  to  AQUA’s  experiences  prestored  in  a  dynamic  episodic  memory.  Based 
on  the  similarities,  AQUA  can  classify  the  user’s  problem  and  then  construct  different 
advice  based  on  the  type  of  problem. 


In  a  similar  vein,  SUSI  ([Jerrams-Smith,  1986]),  USCSH  ([Matthews  and  Biswas, 
1986]),  and  the  SINIX  Consultant  SC  ([Kemke,  1987]),  provide  direct  interfaces  to 
UNIX*  (or  SINDC)  These  systems  concentrate  on  detecting  user  mistakes  or 
inefficiencies  as  users  interact  with  UNDC  (or  SINDC),  and  then  either  correcting  the 
use?s  mistakes  or  suggesting  more  efficient  plans.  The  PASSIVIST  and  ACTIVIST  sy. 
terns  ([Fischer  et  al.,  1985])  attack  the  same  problem  in  the  domain  of  using  the  BISY 


editor. 

The  EUROHELP  project  ([Breuker  et  al.,  1987]  and  [Breuker,  1987])  has  concen¬ 
trated  on  coaching  strategies  for  teaching  the  user  once  the  system  has  detected  a  user 
problem  from  monitoring  the  user  in  action.  A  prototype  EUROHELP  system  has  been 
implemented  for  the  domain  of  UNIX-Mail. 

In  the  domain  of  the  VAXA^MS  operating  system,  the  WIZARD  system  ([Shrager, 
1981],  [Shrager  and  Finin,  1982],  and  [Finin,  1983])  monitors  users,  and  pops  up  a  help 
window  when  it  detects  inefficient  usage  of  VMS  commands  by  the  user. 
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There  are  many  differences  between  these  systems  and  UC,  both  in  their  approach 
to  the  domain  and  in  their  implementations.  For  example,  the 

tratts  more  on  complex  domain  planning  and  less  on  natural  undersantog*^ 

UC.  The  AQUA  system  concenuates  on  a  pamuteaspemo^conul^  ACTTOS-^and 

Hnmain  nlan-oriented  user  misconceptions.  The  SUSI,  UbUbii,  CiU  . 

WIZARD  systems  concentrate  on  active  help  in  which  the  systems  look  over  die 
^^er  of  L  user.  Finally,  the  EUROHELP  project  has  concentrated  on  coachmg  stra- 

tegies  for  teaching  the  user. 

In  terms  of  this  thesis,  the  most  important  difference  between  these  other  systems 
and  UC  is  that  the  other  systems  are  not  implemented  as  mtelligent  agents. 
some  of  these  systems  address  some  of  the  same  issues  as  the  intelligent  agent  part  of 
UC  none  of  these  systems  address  all  of  the  issues.  So,  AQUA  and  many  of  acnve 
help  systems  can  volunteer  advice  and/or  handle  some  user  misconcepaons  ^ut  none  of 
dieL  s^s^ms  would  ever  refuse  to  help  the  user  when  it  is  inappropnate  to  do  so  Of 
bourse  rne  ca^  always  put  in  ad-hoc  rules  to  look  for  special  cases,  but  such  systems 
would  have  difficulty  detecting  interactions  (both  positive  and  negauve)  among  rules.  To 

a  principled  fashion,  a  ^y^^^hould  >rave  irs  own^als,  pl^. 
and  meta-plans  to  deal  with  interactions  among  its  plans  and  goals.  In  short,  system 
should  be  structured  as  an  intelligent  agent. 


C 


L 


L 
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Chapter  11 

KNOME:  UCEgo’s  User  Modeler 


1.  Introduction 


An  intelligent  agent  needs  to  have  a  model  of  its  environment  in  order  to  act  intelli¬ 
gently  In  the  case  of  an  intelligent  agent  that  plays  the  role  of  a  consultant,  a  large  part 
of  thi agent’s  environment  is  the  client  of  the  consultant.  Since  the  mam  job  of  a  consul¬ 
tant  is  to  impart  knowledge  to  its  client,  a  consultant  system  that  is  an  intelligent  agen 
needs  to  have  a  model  of  its  user’s  knowledge  and  beliefs.  In  particular  an  intel  ig 
coSlultant  system  needs  a  user  model  in  order  to  detect  situations  in  which  user  s 
knowledge  is  incorrect  (misconceptions)  and  situations  m  which  the  user  lacks  neede 
informatfon.  In  such  case  the  intelligent  consultant  should  take  the  initiative  to  correct 
the  user’s  misconception  or  inform  the  user  of  the  needed  mformation,  respectively. 

Besides  being  useful  in  volunteering  information  and  correcting  misconceptions,  a 
model  of  the  user’s  knowledge  allows  a  natural  language  interface  to: 

1)  avoid  telling  the  user  something  that  the  user  already  knows 

2)  tailor  explanations  for  the  user’s  level  of  understanding 

3)  utilize  the  user’s  background  knowledge  in  interpreting  what  the  user 
says 

The  KNOME  (KNOwledge  Model  of  Expertise)  component  provides  UC  with  a 
model  of  what  its  users  know.  KNOME  infers  specific  facts  about  what  a  user  does  or 
does  not  know  from  a  dialog  with  the  user,  and  combines  this  evidence  to  infer  the  usw  s 
level  of  expertise.  Then,  KNOME  uses  this  judgment  of  the  user’s  e^ertise  to  predic 

ire  likelihL  that  the  user  might  know  other  fa«s.  KNOME’s 
knowledge  is  made  available  to  other  components  of  UC,  including  UCEgo,  UCExpress, 
and  PAGAN  (the  goal  analyzer).  These  components  utilize  KNOME  s  model  of  the 
user’s  knowledge  to  respond  more  intelligently  to  the  user. 

1.1.  Some  UC  Examples 

To  see  how  KNOME  can  infer  a  user’s  level  of  expertise  from  a  conversation  with 
the  user,  and  how  this  information  can  be  used  advantageously  by  UC  in  helping  the  user, 
consider  the  two  UC  sessions  shown  in  Figures  2.1  and  Figure  2.2. 


c 
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Welcome  to  UC  (Unix  Consultant)  version  3.23 
To  a  pron^Jt,  please  type  in  your  questions 

about  the  UNIX  file  system  in  English. 

To  leave,  just  type  ' "D'  or  ' (exit) ' . 


How  can  I  help  you? 

#  How  can  I  delete  a  file? 

Use  rm. 

For  example,  to  delete  the  file  named  foo,  type  'rm  foo' . 

#  What  does  r uptime  do? 

ruptime  is  used  to  list  the  uptime  of  all  machines  on  the  network, 
list  the  number  of  all  users  on  them,  and  list  their  load  average . 


Figure  2.1.  UC  session  with  Userl. 


c 


Welcome  to  UC  (Unix  Consultant)  version  3.23 
To  a  '#'  proii?>t,  please  type  in  your  questions 
about  the  UNIX  file  system  in  English. 

V  To  leave,  just  type  ' ‘D'  or  ' (exit) ' . 

Hi. 

How  can  I  help  you? 

#  How  can  I  find  out  the  inode  of  a  file? 

Use  Is  -i. 

#  What  does  ruptime  do? 

ruptime  is  like  uptime,  except  ruptime  is  for  all  machines  on  the 
^  network . 


Figure  2.2.  UC  session  with  user2. 


V 
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The  user  of  the  first  session,  Userl,  is  apparently  a  novice  who  knows  very  little 
about  UNIX.  After  all,  Userl  does  not  even  know  something  as  simple  as  how  to  delete 
a  file  (the  subject  of  Userl ’s  first  question).  On  the  other  hand,  the  user  in  the  second 
session,  User2,  knows  what  an  inode  is,  a  relatively  complex  UNIX  concept.  So  User2  is 
probably  a  much  more  advanced  user  of  UNIX  than  Userl.  KNOME  uses  this  type  of 
evidence  about  particular  facts  that  users  know  or  do  not  know  in  order  to  deduce  their 
level  of  expertise. 

Based  on  the  different  levels  of  expertise  of  the  two  users  as  deduced  by  KNOME, 
UC  is  able  to  provide  qualitatively  different  answers  to  the  two  users.  In  the  first  answer 
to  Userl,  KNOME  gives  an  example  of  the  format  of  the  rm  command  (simply  “rm” 
followed  by  the  name  of  the  file  to  be  deleted).  UC  gives  an  example  of  the  format  to 
Userl,  since  a  user  as  unsophisticated  as  Userl  probably  would  not  know  the  format  of 
rm.  On  the  other  hand,  User2  is  a  more  advanced  user  who  undoubtedly  already  knows 
the  format  of  Is.  Hence  UC  is  able  to  give  a  very  concise  answer  to  User2’s  first  query, 
“Use  Is  -i,”  that  does  not  include  an  example  of  the  format  of  Is.  This  illustrates  how 
KNOME  is  used  to  avoid  telling  the  user  something  that  the  user  already  knows. 


The  second  query  of  both  users  is  the  same.  For  the  more  advanced  user,  UC  was 
able  to  explain  the  mptims  command  in  terms  of  a  similar  command,  uptime,  that  the 
more  advanced  user  presumably  already  knows.  Such  a  simile  would  not  work  for 
Userl,  since  a  novice  user  probably  would  not  know  the  uptime  command,  and  so  could 
not  exploit  the  simile  to  understand  ruptime.  KNOME’s  modeling  of  the  user’s 
knowledge  allows  UC  to  choose  whether  or  not  to  use  different  forms  of  presentation  like 
similes  based  on  whether  or  not  the  user  will  understand  them. 


1.2.  Problems  in  Modeling 


There  are  many  difficulties  in  building  and  maintaining  a  model  of  what  the  user 
knows.  The  system  must  first  determine  what  the  user  knows,  and  then  represent  this 
information  internally.  To  determine  the  user’s  knowledge  of  the  domain,  the  system 
could  quiz  the  user  exhaustively.  However  for  most  domains,  such  a  quiz  would  be 
extremely  time  consuming  and  most  users  would  not  consent  to  such  extensive  quizzing. 
Fortunately,  users  tend  to  learn  domain  knowledge  in  a  predictable  order,  so  the  system 
can  make  additional  inferences  about  what  a  user  is  likely  to  know  or  not  know  based  on 
a  partial  user  model.  That  is,  the  user  modeling  system  should  be  able  to  predict  a  user  s 
knowledge  based  on  partial  information  about  what  the  user  knows  or  does  not  know. 
Exactly  which  predictions/inferences  are  allowable  is  problematic.  This  is  the  key  prob¬ 
lem  for  any  user  modeling  system  that  wishes  to  take  advantage  of  the  order  in  which 
users  typically  gain  knowledge  in  a  domain. 

Besides  the  basic  question  of  which  inferences  are  allowable,  there  is  also  the  prob¬ 
lem  of  uncertainty.  Making  inferences  about  the  user  based  on  limited  prior  knowledge 
about  the  user  is  a  form  of  default  reasoning.  Such  default  reasoning  is  not  always  valid, 
so  the  system  needs  to  be  able  to  handle  the  fact  that  such  inferences  are  uncertain.  Usu¬ 
ally  this  requires  that  the  user  modeler  be  able  to  judge  the  certainty  of  its  default  infer¬ 
ences.  Also,  as  the  system  obtains  more  concrete  information,  it  must  be  able  to  update 
its  user  mcxlel.  The  new  information  may  contradict  previous  predictions,  so 


-37- 


maintenance  is  not  simple. 

Another  problem  concerns  the  organization  of  the  inferences.  Many  inferences  tend 
to  be  eroimed  together,  because  people  tend  to  go  through  distinct  stages  of  learning  (see 
TKav  fnd  Black^  1985]).  People  at  a  particular  stage  of  learning  tend  to  have  similar 
toowlSge  has  deterJned  its  user’s  level,  it  can  assume  that  this  user 

taowsISu.  as  much  as  odier  users  at  ttrat  level.  A  good  user  modebng  system  needs  to 
group  such  inferences  together  in  a  simple  and  efficient  manner. 

Another  problem  in  user  modeUng  is  how  to  represent  the  model  intem^ly.  The 

•  1  kTe  overlay  model  ([Carr  and  Goldstein,  1977])  wherem  the  user  s 

simplest  method  is  the  ^  ^  knowledge.  However,  a  simple 

weriay  Side/cSnotVedict  what  a  user  might  know  based  on  partial  information.  An 
overlap  model  does  not  represent  the  order  in  which  users  typically  leam  information  in  a 
domain  What  is  needed  is  a  model  that  represents  such  ordenng  information  in  a 
manner  useful  for  prediction  of  what  a  user  might  know  based  on  partial  information. 

1.3.  Other  User  Models 

User  models  have  appeared  frequently  in  Intelligent  Tutoring  Systems  (e.  g.  [B^on 
and  Bmwn  W61  [SleeZ.  and  Bmwn,  1982]).  [Kass,  1987]  provides  a  su^ey  of  user 
m^L  in  ITS  Typically,  ITS  use  some  variant  of  the  simple  overlay  modei  acarr  ^d 
Goldstein  1977])'^Ovetlay  models  encode  the  user’s  knowledge  as  a  subset  of  the 
?vstemT;xpert  Lwledge  base.  One  variant  is  to  encode  users  as  a  collection  of  dtff«- 
ences  ftom^  the  system’s  built-in  expert.  Differences  may  include  a  lack  of 
know^rroTahve  to  an  expert.  This  is  frequently  augmented  by  “ '-^ra^^f 
orocedures/rules  that  are  common  among  users  (e.  g.  [Brown  and  Burton,  197  ], 
fsmvenTrr  1979],  [Sleeman  and  Smith,  1981],  [Johnson  and  Soloway,  1984] 
Anderin  et  ai’  1985],  and  [Reiser  et  al.,  1985]).  These  types  of  user  models  ^e  not 

designed  to  predict  a  user’s  knowledge  based  on  partial  information  about  what  the  user 
designea  lo  p  inference  is  not  so  appropnate  for  ITS 

wheTe  t^e  Sem  eSHo  kSp  raccurate  user  model.  On  the  other  hand,  consultation 
Tvs^rms  usuX  do  not  interact  with  a  single  user  for  as  much  time  as  tutonng  systems,  ^ 
thev  do  not  have  the  time  to  buUd  a  complete  user  model.  In  such  cases,  default  reaso 
Ing  is  needed.  Therefore,  consultation  systems  need  a  different  type  of  user  model  than 

is  commonly  found  in  ITS. 

ex“d  to  ptdiction  of  I  user’s  knowledge  of  less  related  topics.  For  sample,  such  a 
system  could  predict  that  a  user  has  high  proficiency  ■"  P™cess 

“h  as  using  the  cat  command,  based  on  the  system’s  knowledge  of  the  user 
proficiency  in  process  monitoring  commands. 
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Other  user  models  have  been  built  to  model  a  number  of  aspects  of  the  user  (see 
[Wahlster  and  Kobsa,  1986]  for  a  survey).  For  example,  Grundy  ([Rich,  1979],  [Rich, 
1983],  and  [Rich,  1987])  modeled  user  personality  traits.  Grundy  used  \xs,Qr  stereotypes 
to  group  default  inferences  about  user  traits,  then  used  these  traits  for  suggesting  books  to 
the  user  for  reading.  To  determine  which  stereotypes  were  applicable  to  a  pmicular  user, 
Grundy  asked  the  user  for  a  self  description  at  the  start  of  a  session.  Individual  phrases 
(e.  g.  self  descriptions  such  as  athletic  or  feminist)  would  trigger  stereo^es  that  were 
likely  to  apply  to  that  user.  Such  an  approach  worked  well  for  modeling  personaUty 
traits,  but  does  not  carry  over  to  modeling  domain  knowledge.  A  user  s  self  description 
as  a  “beginner”  often  will  not  coincide  with  the  system’s  idea  of  a  “beginner.”  Also, 
stereotype  triggers  cannot  be  used  to  make  inferences  such  as  inferring  that  the  user  does 
not  know  something  when  the  user  asks  about  it  Stereotype  triggers  are  not  sufficient 
for  inferring  what  users  know. 

Another  use  of  user  models  is  for  representing  user  preferences.  The  hotel  reserva¬ 
tion  system  of  HAM-ANS  ([Hoeppner  et  al.,  1984]  and  [Morik,  1987])  and  the  Real 
Estate  Agent  ([Morik  and  RoUinger,  1985])  chose  different  hotel  rooms  or  apartments 
based  on  users’  needs  and  preferences.  These  systems  expect  users  to  mention  at  the 
start  of  their  session  their  requirements  and  preferences  for  a  room/apartment.  Such  an 
approach  works  well  in  domains  where  users  tend  to  specify  thefi  needs  and  preferences 
at  the  start  of  a  session.  However  this  is  not  tne  case  in  consultation  domains  where  users 
are  unlikely  to  mention  their  level  of  expertise  in  the  domain  at  the  start  of  a  session. 

Many  systems  including  UC  have  modeled  the  user’s  plans  and  goals  (e.  g.  [Allen 
and  Perrault,  1980],  [Carberry,  1983]  and  [Carberry,  1987],  [Litman  and  Allen,  1984], 
[Johnson  and  Soloway,  1984],  [Wilensky,  1986]).  Such  systems  infer  the  user’s  plans 
and  goals  by  matching  the  user’s  actions  to  steps  of  prestored  plans.  This  type  of  infer¬ 
ence  works  well  for  detecting  the  user’s  plans,  but  does  not  extend  to  determining  what 
the  user  does  or  does  not  know. 


2.  Internal  Representation  of  Users 

KNOME  represents  what  UC  believes  users  know  about  UNIX.  In  this  sense, 
KNOME’s  model  of  the  user  is  not  necessarily  meant  to  accurately  model  actual  users, 
but  is  meant  to  conform  to  the  way  human  UNIX  consultants  model  their  clients.  So  in 
developing  KNOME’s  user  models,  no  attempt  was  made  to  psychologically  profile  what 
different  users  know.  Instead,  former  UNIX  consultants  (UC’s  implementors)  were 
informally  surveyed  to  determine  how  they  viewed  users. 

2.1.  Double-Stereotypes 

Humans  use  categorization  to  organize  inferences  (see  [Rosch,  1977],  [Rosch, 
1978],  and  [Rosch,  1983]).  These  categories  serve  as  reference  points  or  prototypes  for 
judging  objects.  Once  an  object  has  been  identified  as  belonging  to  a  particular  category, 
default  inferences  about  the  object  can  be  made  based  on  the  object  s  membership  in  the 
category. 
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An  approach  similar  to  human  categorization  is  used  in  KNOME  to  organize  infer¬ 
ences  concerning  users.  In  KNOME,  users  are  grouped  according  to  their  level  rfexpe 
rise  in  using  UNIX.  Each  group  is  represented  by  a  prototype-style  category^ 
forsuch  ?at^es  in  UC:  Lee,  ie^inner.  — mte  and  expen.  Each  of  the 

categories  represents  an  increasing  mastery  of  UNIX  information.  .... 

Individual  users  are  represented  as  members  of  one  of  these  categones  and  inhent 

SjOME's  stereotypes  are  integrated  into  KODIAK’S  multiple  mhentance  hierarchy  and 

its  default  inheritance  mechanisms.  .  .  ,  ,  f 

Resides  cate<^orizing  users,  KNOME  also  categorizes  information  into  levels  ot 

3trir=  r-s- 

of  the  command  followed  by  the  name  of  the  file  to  be  operated  upon).  P 

technical  term  “working  directory,"  and  the  -1  option  of  Is.  f 

cents  are  the  orep  cbmod,  and  tset  commands,  the  term  mode,  md  the  fact  that 

write  permission  on  the  containing  directory  is  a  precondition  for  using  the  rm  comman 

for  deleting  a  file.  Complex  concepts  are  learned  relatively  late  by  the  typical  us  . 

"don  to  the  diree  previously  mentioned  levels  of  difficulty  KNOME  has  the 
cateaorv  etreric  that  includes  information  that  is  not  typically  learned  at  any  p^cular 
“age  of  «periLrSuch  concepts  are  learned  only  when  users  have  special  need. 
Some  tnav  S  familiar  to  beginners,  yet  unfamiliar  to  many  experts.  An  example  of  an 

esoteric  command  is  spice,  a  program  used  for  '“I"  „  ™spte°e"'  TOsVoup 

pie  who  need  to  perform  circuit  simulations  would  know  how  to  use  spice.  F  P 

wuld  likely  include  beginning  users  as  well  as  inteimediate  and  ' 

other  hand,  there  are  many  expert  UNIX  users  who  ^o* 

they  have  never  needed  to  perform  semiconductor  cu-cuit  simulano  . 

Once  information  has  been  classified  into  levels  of  difficulty,  inferences  based  on 
user  stereotypes  can  easily  be  represented  as  relations  between  the  various 
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between  different  user  stereotypes  and  different  knowledge  difficulty  levels. 


MUNDANE 


Figure  2.3.  KODIAK  representation  of:  intermediates  know  most  mundane  facts. 


User 

Stereotype 

Knowledge  Difficulty  Level 

simple 

mundane 

complex 

esoteric 

expert 

ALL 

ALL 

MOST 

— 

intermediate 

ALL 

MOST 

AFEW 

— 

beginner 

MOST 

AFEW 

NONE 

— 

novice 

AFEW 

NONE 

NONE 

NONE 

Table  2.1.  Relation  between  user  stereotypes  and  knowledge  difficulty  levels. 

The  use  of  stereotype  categories  for  both  users  and  information  is  an  example  of  a 
double-stereotype  system.  Single  stereotype  systems  like  Grundy  used  stereotypes  for 
users  (e.  g.,  FEMINIST,  INTELLECTUAL,  SPORTS-PERSON)  but  not  for  information 
(i  e,  Grundy  did  not  have  stereotypes  for  books  such  as  GOTHIC-ROMANCE, 
DETECTIVE-STORY,  or  SCIENCE-FICTION).  KNOME  is  the  first  user  modeling  sys¬ 
tem  to  utilize  double-stereotypes. 

The  use  of  stereotypes  allows  KNOME  to  predict  what  users  are  likely  to  know  or 
not  know  based  on  a  partial  user  model.  Once  KNOME  has  accumulated  a  small  number 
of  facts  (typically  -?>r  about  what  users  do  or  do  not  know  during  the  course  of  a  UC  ses¬ 
sion,  it  can  infer  the  user’s  level  of  expertise  (see  Section  3).  Then  based  on  the  user  s 
levei  of  expenise,  KNOME  can  predict  whether  or  not  the  user  is  likely  to  know  other 
facts  The  small  set  of  facts  that  allows  KNOME  to  infer  the  user’s  level  of  expertise 
constitutes  a  partial  user  model,  and  the  inference  that  the  user  belongs  to  a  particular 

2  The  actual  number  varies,  because  facts  may  mutually  reinforce  KNOME’s  evaluation  of  the  user’s  lev¬ 
el  of  expertise,  in  which  case  fewer  facts  will  be  need^;  or  facts  may  provide  contradictory  evidence,  m 
which  case  more  facts  will  be  needed  to  evaluate  the  user’s  level  of  expertise. 
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stereotype  represents  a  set  of  default  inferences  that  are  made  on  the  basis  of  the  partial 

usermcxiel.  .  r-  i  •  r 

The  use  of  stereotypes  allows  KNOME  to  efficiently  group  these  default 
together  A  system  that  did  not  use  stereotypes  would  need  to  represent  mdivid^ly 
every  partial  Ler  model  and  all  the  default  inferences  from  that  partial  user  model. 
SinS  a  partial  user  model  is  simply  a  set  of  facts  about  a  user,  there  is  a  combm^oncally 
large  number  of  partial  user  models.  So,  representing  all  such  partial  user  m^e  s  a^d 
thei  default  inferences  would  be  extremely  inefficient.  However  mai^  partial  user 
models  have  similar  default  inferences.  These  can  be  grouped  together  efficiently  using 
user  stereotypes.  A  double- stereotype  system  is  even  more  efficient,  since  it  allows  th. 
system  to  e^ode  for  each  fact  only  its  level  of  difficulty  rather  than  having  to  enc^e  iB 
rLtionship  to  every  user  stereotype.  The  rest  of  a  double- stereotype  system  c^  dien  be 
encoded  in  a  small  number  of  statements  relating  the  two  levels  of  stereotypes.  This  re  a- 
tionship  in  KNOME  between  user  stereotypes  and  knowledge  difficulty  levels  is  sum¬ 
marized  in  T able  2.1. 

KNOME  currently  has  only  one  double-stereotype  range  for  u^  .^^is  ^ge 
represents  user's  knowledge  of  UNIX  file  manipulanon  comrmnds,  infomanon 

gartering  commands,  and  UNIX  concepts  and  terminology.  This  ^  * 

Ltnain  of  expertise  within  UNIX.  If  UC  were  extended  to  cover  more  of  UNIX  or  even 
other  operating  systems,  then  KNOME  would  need  more  ranges 
For  example,  if  UC  also  covered  usage  of  the  vi  and  emaos  'hen  IWOME  would 

need  separate  expertise  ranges  for  each  of  these  domains.  KNOhffi  would  ''l^o  nc^  to 
encode  how  the  user’s  level  of  expertise  in  one  domain  mighl  be  used  to  p^ct  rte 
user's  level  of  expertise  in  another  domain.  So,  an  expert  in  using  vi  would  undoubtedly 
have  a  high  level  of  expertise  in  manipulating  the  UNIX  ffle  system.  On  'h* 
a  high  level  of  expenise  in  using  emacs  does  not  necessanly  mdicate  a  high 
expe^rtise  in  using  UNIX,  since  rte  emacs  editor  is  commonly  found  in  other  operating 

systems. 

2.2.  Modeling  Individual  Users 

Individual  users  usually  do  not  completely  fit  any  one  stereotype  Asa  result,  a  user 
model  that  uses  stereotypes  must  also  encode  how  individual  users  differ  from  stereo¬ 
types  KNOME  stores  specific  information  about  what  individual  users  toow  and  do  not 
Jow.  Such  information  is  stored  as  a  collection  of  propositions  a^ut  what  ^ 
or  does  not  know.  These  propositions  are  represented  using  KODIAK.  In  re^o  g 
about  what  a  user  knows,  this  collection  of  individual  facts  is  checked  before  resorting  to 

reasoning  from  the  user’s  stereotype  category. 

To  avoid  storing  too  many  individual  facts  about  what  users  know,  only  those  facts 
that  cannot  be  inferred  with  high  likelihood  from  a  user’s  category  are  '  F” 
pie  the  fact  that  a  particular  intermediate  user  knows  the  rm  comirrmd  (a  simple  com- 
malid)  does  not  need  to  be  stored  explicitly,  since  it  is  duectly  inferable  from  the  fact  that 
rldTal  users  know  all  simple  facts.  Also,  the  fact  that  a  particular  beg, nner  taows 
rte  rm  command  does  not  need  to  be  stored.  This  is  because  7“  J™; 

pie  facts  and  hence  it  is  likely  that  any  particular  beginner  would  know  rm.  On  the  other 
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hand  the  fact  that  a  particular  novice  knows  the  rm  command  does  need  to  be  stored 
L“uddy,  sin«  fta.  fs  no.  inferable  with  high  likelihood.  Because  novroe  users  know 
just  a  few  simple  facts,  it  is  unlikely  that  any  particular  novice  would  know  rm. 

2.3.  Types  of  Knowing 

In  UC,  two  senses  of  “know”  are  used.  The  first  is  the  classical  sense  of  toow:  the 
knower  believes  that  some  proposition  P  is  true,  and  P  is  true.  An  example  of  this  sense 
of  knowing  is:  “  the  user  knows  that  the  cd  command  is  used  to  ^ange 
working  directory.”  There  is  also  another  sense  of  know  that  is  found  in  UC.  Tins  se  s 
of  know  is  closer  to  the  colloquial  usage  wherein  knowmg  an  object  means 
liar  with  that  object.  However,  in  UC  this  vague  usage  is  made  precise  For  UC,  know¬ 
ing  a  command  such  as  the  UNIX-RM-COMMAND  implies  knowing  that  there  exists  a 
command  with  the  name  rm,  knowing  the  main  purposes  of  this  command,  ^o^mg  Ae 
format  of  the  command,  knowing  the  main  effects  of  the  command,  and  knowing  the 

main  preconditions  of  the  command. 

The  main  purposes  of  a  command  are  represented  in  UC  using  the  planfor  ([Chin, 
1983a]  and  [Wilensky  et  al.,  1986])  relation,  which  relates  a  goal  and  the  plan  that  is  t^- 
L  Jly  used  to  satisfy  "diat  goal.  The  planfors  of  a  pl^  are  different  rom  the  effocts  o^ 
Dlan  since  not  all  of  a  plan’s  effects  can  be  considerea  goais  mat  Jic  pion  la  lypkcaiiy 
Led  to  satisfy.  All  goals  in  the  planfors  of  a  command  are  also  effects  of  the  command, 
but  some  side  effects  of  the  command  may  not  be  part  of  its  planfors.  For  instance,  c  - 
ling  the  game  program  rogue  with  a  file  argument  has  a  side  effect  that  is  not  found  in 
the  planfors  of  rogue.  When  rogue  is  given  a  file  argument  that  is  not  a  rogue-forma 
ave  rogue  arbitrarily  rmoves  the  file.  This  is  a  side  effect  of  the  rogue  pro- 

but  it  is  not  in  any  planfors,  since  users  do  not  typically  run  rogue  in  order  to 

remove  files. 

2.4.  Dealing  with  Uncertainty 

In  any  user  model,  the  inferences  that  the  model  makes  about  the  user  contains 
some  degree  of  uncertainty.  In  KNOME,  an  attempt  was  made  to  avo.d  the  use  of 
numeric  representations  of  uncertainty,  because  their  use  tends  to  lead  systems  " 

timate  the  accuracy  of  their  ratings  of  uncertainty  fe.UC  uses  “ 

rating  levels  instead:  LIKELY,  UNLIKELY,  VERY^IMLY  VERY-UNLIKELY, 
SOhffiWHAT-LlKELY,  SOMEWHAT-UNLIKELY,  TRUE,  FALSE,  and  UNCTR- 
TAIN  (c.  f.  fuzzy  logic  [Zadeh,  1965]).  KNOME  also  uses  predicates  such  as  AFEW 

MOST  ALL,  and  NONE  (c.  f.  [Zadeh,19821).  ® 

KNOME  to  express  the  certainty  of  its  infemnces.  For  example,  when  WOME  is  asM 
whether  an  particular  user  knows  some  particular  fact,  it  will  return  euher  TRU 

T  TKELY  UNLIKELY  FALSE,  or  UNCERTAIN.  TRUE  and  FALSE  indicate  that 
LIKELY,  U^Ltivti.1,  ,  ,  uj^jjQgLY  indicate  some  uncertainty. 

KNOME  has  complete  confidence.  LIKELY  ana  ui>Liivr.i- 1 

An  UNCERTAIN  result  indicates  that  KNOME  does  not  have  enough  information  to 
guess  whether  the  user  does  or  does  not  know  that  fact. 
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To  deduce  whether  a  particular  user  knows  some  particular  fact,  KNOlvE  uses  a 
multi-step  inference  process.  First,  KNOME  checks  the  individual  user  model  for  that 
user  If  die  individual  user  model  records  that  this  user  does  or  does  not  know  this  fact, 
then  the  answer  is,  respecdvely,  TRUE  or  FALSE.  If  there  is  no  specific  information  in 
die  user's  individual  user  model,  KNOME  next  checks  the  stereotype  category  of  the 
user.  If  users  of  the  user's  stereotype  do  or  do  not  know  that  fact,  then  the  answer  is 
again  TRUE  or  FALSE,  respectively.  If  these  checks  fail,  KNOME  resorts  to  inference 
bLed  on  the  difficulty  level  of  the  fact  If  the  user's  stereotype  kno«  ALL  facts  of  *a 
difficulty  level,  then  the  answer  is  TRUE;  if  the  stereotype  taows  MOST  facts  of  ha 
difficulty  then,  the  answer  is  LIKELY;  and  if  the  stereotype  knows  AFEW  facts  of  that 
difficulty,  then  the  answer  is  UNLIKELY.  Finally,  if  this  process  fails  due  to  lack  of 
infoimadon,  then  the  answer  is  UNCERTAIN.  This  algorithm  is  summanzed  in  the  flow 

chart  of  Figure  2.4. 


Figure  2.4.  Algorithm  for  determining  whether  User  knows  Fact. 


3.  Deducing  the  User’s  Level  of  Expertise 

One  of  the  main  problems  in  user  modeling  is  how  to  build  up  a  model  of  a  particu¬ 
lar  user.  In  a  user  modeling  system  based  on  stereotypes,  this  means  deterrranmg  which 
slereotype(s)  best  fit  the  current  user  and  how  that  user  differs  from  the  stereowe^  n 
UC,  this  means  that  KNOME  must  determine  the  user' s  level  of  expertise  in  using  UNIX. 
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3.1.  Other  Model  Acquisition  Systems 

Various  approaches  to  building  up  models  of  users  have  been  used.  Some  systems 
such  asX  Re^  Estate  Agent  ([Morik  and  Rollinger,  1985])  expect  users  to  mention 
enough  self-characteristics  at  the  start  of  a  session  so  that  the  system  can  build  up  th 
user  Sxiel  This  works  for  situations  such  as  a  real  estate  agent  interchange  with  a  client 
where  the  client  is  likely  to  mention  what  he/she  needs/wants  at  the  beginning  of  a  dia- 
Tog  Howev  r'this  does  not  extend  to  other  consultation  situations  where  the  user  usu- 
2  ^11  not  mention  what  he/she  knows  at  the  start  of  a  session.  In  such  — tion 
simations  the  user  typically  begins  by  describing  his/her  problem  to  the  consultant. 

Another  approach  is  to  ask  the  user  for  a  self-description  at  the  start  of  a  session  as 
in  Grundy  [Rich,  1979]).  This  is  a  reasonable  approach  forjudging  the  user  s  personality 
traits  but  does  not  work  well  for  determining  what  the  user  knows.  For  die 

user’s  level  of  expertise,  this  approach  is  inaccurate,  since  the  user  s  concept  of  different 
levels  of  expertise  like  “intermediate”  may  differ  considerably  from  the  system  s  con¬ 
cept  or  users’  concept  of  an  “intermediate.”  Also,  this  requirement  is  not 

very  practical  for  occasional  users,  since  this  increases  the  overhead  of  using  the  system. 

A  third  approach  is  to  quiz  users  at  the  start  of  a 

user’s  expertise.  For  example,  the  MAP  system  ([Macmillan,  1983])  helps  a 
27m  spe  fy  a  correct  user  model  of  how  that  user  interacts  with ^  operating  system. 
Such  2  approach  is  extremely  time  consuming.  For  tasks  like  intelligent  operanng  sys- 
tern  interfLes  for  which  MAP  was  designed,  such  a  protracted  proems  is  ™ 

acceptable  since  the  user  will  realize  its  benefits  over  a  long  penod  of  time  However 
for  iLracring  with  a  consultation  system  like  UC  where  typical  sessions  are  short,  such  a 
moiess  w2ld  be  too  time  consuming.  The  casual  user  that  only  needed  the  answer  to  a 
Lgle  question  would  be  better  off  without  a  user  model  rather  than  having  to  put  up 

with  such  a  lengthy  process. 

The  most  common  approach  in  ITS  amelligent  Tutoring  Systems)  is  to  compare  the 
user’s  performance  with  what  a  built-in  expert  would  do.  Differences  in  performance 
c»  tobe  attributed  to  either  a  lack  of  user  knowledge  or  differences  tn  user  kiiowl  dge 
such  as  improper  procedures  or  rules.  However  such  an  approach  is  only  applicable  if 
he  system  can  “iL  over  the  shoulder”  of  the  user.  Consultation  systems  f  e"  cannm 
obseL  the  user  at  work.  Even  when  this  is  possible,  consultation  systems  should  not  be 
expected  to  constantly  observ'e  the  user,  since  human  consultants  do  not  do  so. 

To  properly  emulate  a  human  consultant,  the  system  should  be  able  to  assess  the 
expertXel  of  the  user  while  talking  to  the  user.  None  of  the  preiaously  mentioned 
approaches  model  this  ability,  which  is  a  difficult  problem  in  natural  language  under- 
sranding  One  system  that  has  addressed  this  problem  is  the  VIE-DPM  user  modehng 
systL  ([Kobsa,  1985al).  However,  VIE-DPM  uses  only  a  syntacnc  interpretation  of  *e 
Sris  statements  to  derive  the  user’s  beliefs.  VIE-DPM  makes  assumptions  about  the 
user’s  beliefs  based  on  the  form  of  the  user’s  input  (a  yes/no  question,  a  wh-question,  or  a 
command)  ([Kobsa,  1985a]  and  [Kobsa,  1986])  or  the  presence  of  linguistic  pamcles 
(e  g  ’’not”)  in  the  user’s  input  ([Kobsa,  1985b]).  Such  a  syntax^nly  system  would  not 
£  !ble  to  properly  interpret  phenomena  such  as  indirect  speech  acts  ([Austin  1962], 
TscTc  WsTpor  exaV;  “Can  you  pass  the  salt?”  is  a  yes/no  question,  but  one 
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3.2.  KNOME’s  Approach 

KNOME  uses  the  approach  of  inferring  the  user’s  level  during  the  course  of  a  ses- 
At  tv*<Hnning  of  a  session  UC  has  no  information  about  the  user.  In  such  cases, 

SlDM^reSs  op^n  to  *e  possibility  U-a.  d,o  user  may  Wong  »  ' 

TTNOME  maintains  a  Ust  of  candidate  stereotypes  to  which  the  user  may  be  g. 

KNOME  also  rates  the  likelihood  that  the  user  may  be  a  member  of  any  pamcu  ar  s  ere  - 
A.  fht  ^e  likelihood  ratings  for  membership  in  any  stereotypes  is  neutr^. 

for  the  beeinner  stereotype  The  likelihood  rating  for  beginner  is  initially  slightly 

except  for  the  to  be  beginners  rather  than  novices, 

“fe™ rim  is  gaUmred  aL.  dte  user  during  the  ses- 

sion,  the  stereotypes  may  rise  or  fall  in  likelihood. 

KNOME  deduces  the  user’s  level  of  expertise  using  a  two  phase  process.  First,  d 

3.3.  Collecting  Evidence 

The  first  Step  in  the  process  of  deducing  the  user’s  level  of  expertise  is  to  collect 
•Henre  on  that  subiect  Typically,  such  evidence  takes  the  form  of  individual  facts 
alu.  whauhe  user  Iws  or  tes  no.  know.  Such  facts  ^d  other  forms  °f 
bTdeduced  from  what  the  user  says  (or  does  not  say)  and  from  ^ 

onals  KNOME  distinguishes  six  classes  of  inferences  that  were  ou 
UC  or  tolg  thelser’s  level  of  expertise.  These  inference  classes  are  summan^d 
in  Table  2.2,  which  lists  the  inference  class  and  the  kinds  of  inferences  that  are  c 
monly  found  in  each  inference  class. 


V 


V 
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Inference 

Class 

Kinds  of  Inferences 

Claim 

user  states  that  user  does  (not)  know  ?x  — >  user  does  (not)  know  ?x 

Goal 

user  wants  to  know  ?x  — >  user  does  not  know  ?x 

Usage 

user  uses  ?x  user  knows  ?x 

Background 

user  mentions  his/her  background  — >  user  knows  as  much  as  the 
stereotype  indicated  by  the  background 

Query-Reply 

system  asks  if  user  knows,  user  replies  -»  user’s  reply 

No-Clarify 

system  uses  new  terminology,  user  does  not  ask  for  clarification 
— >  user  understands  terminology 

Table  2.2.  Taxonomy  of  deduction  types  for  inferring  what  users  know. 


The  first  class  of  inferences,  Claim  inferences,  applies  when  the  user  claims  to  know 
or  not  know  something.  The  second  class,  Goal  inferences,  applies  when  the  system  can 
infer  that  the  user  wants  to  know  something.  In  such  cases,  the  system  can  also  infer  that 
the  user  must  not  know  whatever  is  wanted,  since  if  the  user  already  knew  it,  then  the 
user  would  not  have  the  goal  of  knowing  it.  The  third  class.  Usage  inferences,  are  made 
when  the  user  properly  uses  some  command  or  terminology.  KNOME  can  then  deduce 
that  the  user  must  know  the  command  or  terminology.  The  fourth  class,  Background 
inferences,  are  made  when  the  user  mentions  some  relevant  information  about  his/her 
background.  The  fifth  class  of  inference,  Query-Reply,  applies  when  the  system  queries 
the  user  about  the  user’s  knowledge  and  the  user  replies.  The  last  type  of  deduction, 
No-Clarify,  is  made  when  the  system  uses  some  new  terminology  that  the  user  may  or 
may  not  know.  If  the  user  does  not  ask  for  a  clarification  of  the  terminology,  then  the 
system  can  assume  that  the  user  probably  already  knew  the  terminology.  Each  of  these 
classes  of  inference  is  described  in  greater  detail  below. 

Claim  inferences  are  concerned  with  direct  statements  by  the  user  about  what  the 
user  does  or  does  not  know.  Examples  of  such  statements  and  the  inferences  that 
KNOME  makes  based  on  the  statements  include: 
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I  already  know  about  mkdir. 

->  the  user  knows  the  mkdir  command 

I  don’t  know  how  to  move  a  file. 

— >  the  user  does  not  know  how  to  move  a  file 

->  the  user  does  not  know  that  mv  is  a  plan  for  moving  files 

-4  the  user  does  not  know  the  mv  command 


In  the  first  example,  the  user  claims  to  already  know  the  mkdir  command.  This 
statement  is  not  as  straightforward  as  it  might  seem,  since  the  user  and  the  system  may 
not  agree  on  what  it  means  to  know  a  command.  A  reasonable  interpretation  of  what  a 
user  might  mean  is  that  the  user  knows  how  to  use  mkdir,  knows  the  main  purpose  of 
mkdir  and  knows  the  main  effects  and  preconditions  of  mkdir.  This  interpretation  is  the 
same  as  what  UC  means  when  it  encodes  that  a  user  knows  a  command  (see  Section  2.3). 


Of  course,  it  may  be  that  the  system  should  not  believe  the  user’s  statement  about 
knowing  mkdir.  It  is  possible  that  the  user  may  be  confused  and  does  not  actually  know 
mkdir.  But,  there  is  always  doubt  about  what  someone  might  really  know,  no  matter 
how  strong  the  evidence.  For  example,  even  if  the  system  were  to  watch  the  user  use  the 
mkdir  command  successfully,  it  is  possible  that  the  user  may  have  actually  wanted  to 
create  a  file  instead  of  a  directory.  However,  in  none  of  these  cases  is  there  any  reason  to 
doubt  the  user.  Unless  KNOME  obtains  evidence  to  the  contrary,  it  assumes  that  the  user 
really  does  (or  does  not)  know  something  when  the  user  makes  such  a  claim. 

The  second  example  requires  somewhat  more  complex  processing  than  the  first 
example.  In  the  second  example,  the  user  claims  not  to  know  how  to  move  a  file.  Since 
UC  knows  that  mv  is  used  to  move  files,  KNOME  is  able  to  deduce  that  the  user  does  not 
know  that  mv  is  a  plan  for  moving  files.  Finally,  because  the  user  does  not  know  one  of 
the  main  purposes  of  the  mv  command,  KNOME  deduces  that  the  user  must  not  know 


mv. 

KNOME  only  stores  information  about  levels  of  difficulty  for  objects  and  not  for 
descriptions,  so  only  facts  about  a  user  knowing  (or  not  knowing)  specific  objects  (e.  g. 
commands,  concepts,  etc.)  can  be  used  in  deducing  the  user’s  level  of  expenise.  This 
approach  eliminates  redundancy,  since  any  object  will  have  many  possible  descriptions. 
For  example,  the  user  could  have  referred  to  mv  by  “how  to  rename  a  file  rather  than 
“how  to  move  a  file.’’  So,  the  fact  that  the  user  does  not  know  mv  is  useful  for  deducing 
the  user’s  level  of  expertise,  but  the  descriptive  fact  that  the  user  does  not  know  how  to 
move  a  file  cannot  be  directly  used.  UC  must  first  determine  that  this  description  applies 
to  the  mv  command  before  it  can  be  used  for  deducing  the  user’s  level  of  expertise.  In 
UC,  descriptions  of  the  purpose  of  commands  are  interpreted  by  UC’s  UNIX  planner 
component.  After  UC’s  UNIX  planner  has  determined  the  command  referred^  to  by  the 
command  description,  KNOME  can  use  this  information  in  deducing  the  user’s  level  of 


expertise. 

Goal  inferences  apply  when  UC  can  deduce  the  user’s  goals.  If  UC  can  infer  that 
the  user  wants  to  know  something,  ?x,  then  KNOME  can  deduce  that  the  user  does  not 
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know  ?x  and  also  does  not  know  the  answer  to  ?x.  For  example,  if  the  user  asks  How 
can  I  delete  a  file?”  then  UC  can  deduce  that  the  user’s  goal  is  to  know  how  to  delete  a 
file.  From  this  goal,  KNOME  can  deduce  that  the  user  does  not  know  how  to  delete  a 
file.  Then,  after  UC  computes  that  a  plan  for  deleting  a  file  is  to  use  the  rm  comm^d, 
KNOME  can  infer  that  the  user  does  not  know  this  planfor  relation  between  deleting  files 
and  the  rm  command.  Finally,  since  the  planfor  relation  is  central  to  UNIX  commands, 
KNOME  can  deduce  that  the  user  does  not  know  rm  in  the  sense  that  the  user  is  not  fam¬ 
iliar  with  rm  (see  Section  2.3). 

In  UC  the  initial  deduction  about  the  user’s  goal  is  made  by  UC  s  goal  analysis 
component,’ PAGAN  ([Wilensky  et  al..  1986]  and  [Mayfield,  forthcoming]).  PAGAN 
computes  the  user’s  plans  and  goals  from  the  dialogue,  and  can  handle  phenomena  such 
as  indirect  speech  acts.  In  some  cases,  PAGAN  utilizes  KNOME’ s  model  of  the  user  s 
knowledge  in  deducing  the  user’s  goals.  For  example,  if  the  user  asks,  ‘  Do  you  know 
how  to  compact  a  file?”,  then  the  choice  between  the  direct  mterpretation  (the  user  wants 
to  know  if  UC  knows  how  to  compact  a  file)  and  the  indirect  interpretation  (the  user 
wants  to  know  how  to  compact  a  file)  depends  partly  on  whether  or  not  KNOME  'oelieves 
the  user  already  knows  the  compress  command.  If  KNOME  does  believe  that  the  user 
is  likely  to  know  compress,  then  that  will  bias  PAGAN  toward  the  direct  interpretation 
that  the  user  is  testing  UC  (not  uncommon),  and  vice-versa. 

This  process  may  seem  circular,  since  PAGAN’S  analysis  of  the  user  s  goal  depends 
on  KNOME,  while  KNOME’s  analysis  of  the  user’s  knowledge  depends  on  PAGAN. 
However,  KNOME’s  initial  evaluation  of  whether  the  user  knows  is  only  a  prediction 
from  a  p^ial  user  model.  This  prediction  does  not  determine  PAGAN’S  interpretation, 
because  PAGAN  must  also  take  into  account  other  factors  in  its  analysis.  One  such  fac¬ 
tor  is  the  frequency  of  usage  of  the  direct  versus  indirect  inteipretations.  PAGAN  is 
biased  toward  adopting  the  more  frequent  usage.  Another  factor  is  the  *e  context  of  the 
dialog.  When  UC  is  configured  in  knowledge  acquisition  mode  as  UCTeacher  ([Martin, 
19851)  then  the  direct  interpretation  (i.  e.  the  user  is  testing  UC  s  knowledge),  is 
inherently  more  likely  than  the  indirect  interpretation.  KNOME’s  beliefs  about  the  state 
of  the  user’s  knowledge  is  only  one  factor  in  PAGAN’S  analysis,  which  then  leads 
KNOME  to  its  own  inference  about  the  state  of  the  user’s  knowledge. 

Besides  questions  on  how  to  do  something.  Goal  deductions  apply  to  many  other 
kinds  of  queries  such  as: 


What  is  a  directory? 

— >  the  user  wants  to  know  what  is  a  directory  (goal) 

— »  the  user  does  not  know  what  is  a  directory 
— »  the  user  does  not  know  the  directory  concept 

Can  you  tell  me  how  to  find  out  who  is  on  the  system? 

->  the  user  wants  to  know  who  is  on  the  system  (goal) 
the  user  does  not  know  who  is  on  the  system 

What  does  ruptime  do? 

the  user  wants  to  know  the  effects  of  the  ruptime  command  (goal) 
the  user  does  not  know  the  effects  of  the  ruptime  command 
— >  the  user  does  not  know  the  ruptime  command 


All  of  the  above  queries  represent  Goal  deductions,  since  PAGAN  can  deduce  that 
the  user  wants  to  know  some  information.  Based  on  this  initial  deduction,  KNOME  can 
infer  that  the  user  does  not  know  the  information  that  is  sought. 

Usage  deductions  are  made  when  the  user  applies  some  plan/procedure  correctly,  or 
uses  some  specialized  terminology  correctly.  Examples  include: 

I  tried  typing  “rm  foo,”  but  I  got  the  message,  “rm:  foo  not  removed.” 

-4  the  user  knows  the  rm  command 

How  can  I  find  out  the  inode  of  a  file? 

— >  the  user  knows  the  inode  concept 

I  tried  typing  “del  foo”,  but  I  got  the  message  “del:  Command  not  found.” 

— >  the  user  knows  the  DOS  del  command 

-4  the  user  does  not  know  the  UNIX  rm  command 


In  the  first  example,  KNOME  can  deduce  that  the  user  knows  the  rm  plan.  In  the 
second  example,  KNOME  deduces  that  the  user  knows  the  meaning  of  the  term  “inode.” 
This  is  the  main  type  of  deduction  used  in  ITS  in  which  the  system  observes  the  user  at 
work  solving  problems.  This  type  of  deduction  is  suggested  by  [Rich,  1983]  for  consult¬ 
ing  situations. 

In  general,  whenever  the  user  uses  specialized  terminology  correctly,  KNOME 
infers  that  the  user  must  know  the  concept  denoted  by  the  terminology.  In  UC,  terms 
include  UNIX  command  names  and  operating  system  terminology  such  as  “file  protec¬ 
tion”,  “directory,”  and  “inode.”  Checking  that  the  user  used  the  terms  correctly  is  not 
very  sophisticated  in  KNOME.  The  first  check  is  simply  that  the  term  must  be  used  in  an 
English  sentence  that  UC  can  parse  and  understand.  However,  the  fact  that  the  user  used 
a  term  in  an  understandable  sentence  does  not  automatically  mean  that  the  user  knows 
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the  meaning  of  the  term.  For  example,  if  the  user  asks,  “What  does  rm  do.  ,  KNOM 
should  not  infer  that  the  user  knows  the  rm  command.  The  same  principle  apples  when 
the  user  states,  “I  don’t  know  the  rm  command.”  In  these  types  of  sentences,  KNOME 
actually  first  infers  that  the  user  does  know  rm  and  then  reverses  its  inference  laicr  based 
on  the  fact  that  the  user  has  the  goal  of  knowing  the  effects  of  rm,  which  is  a  Goal  type 
inference  In  cases  when  KNOME  has  evidence  both  that  the  user  knows  something  and 
that  does  not  know  it,  KNOME  always  assumes  that  the  user  dwsn’t  know,  smce  it  is 
always  possible  that  the  user  just  seems  to  know  and  in  fact  doesn’t  know. 

The  last  example  is  somewhat  more  complex  than  the  previous  examples.  In  this 
case,  KNOME  first  infers  that  the  user  knows  the  DOS  del  command.  Then,  since  the 
DOS  del  command  is  used  to  delete  files  and  the  user  mistakenly  tried  to  use  the  del 
command,  KNOME  can  deduce  that  the  user  does  not  know  the  UNIX  command  for 
deleting  files,  that  is,  the  rm  command.  In  general,  whenever  the  user  tries  to  use  a 
foreign  command  in  UNDC,  then  KNOME  assumes  that  the  user  does  not  know  the 
corresponding  UNIX  command.  This  correspondence  is  found  by  looking  at  the  goal  of 
the  foreign  command  and  finding  a  UNIX  command  that  is  a  plan  for  the  same  goal. 

Background  deductions  are  made  when  the  system  learns  some  relevant  fact  about 
the  user’s  background.  Examples  include: 


I  am  a  fourth  year  computer  science  graduate  student. 

-4  the  user  is  a  member  of  the  4TH-YEAR-CS-GRAD  stereotype 
-4  the  user  is  LIKELY  to  be  an  EXPERT 

In  my  CS2  class, .  .  . 

-4  the  user  is  a  member  of  the  CS2-STUDENT  stereotype 
^  the  user  is  LIKELY  to  be  a  BEGINNER 


In  the  first  example,  KNOME  infers  that  the  user  is  a  member  of  the  4TH-YEAR- 
CS-GRAD  stereotype.  This  allows  KNOME  to  further  infer  that  the  user  is  LIKELY  to 
be  an  expert,  because  most  4th  year  CS  graduate  students  are  experts.  In  the  second 
example,  UC’s  Concretion  mechanism  infers  from  “my  CS2  class”  that  the  user  is  a 
CS2-STUDENT.  Based  on  this,  KNOME  then  infers  that  the  user  is  a  member  oi  the 
CS2-STUDENT  stereotype,  and  so  is  likely  to  be  a  beginner. 

To  make  Background  deductions,  KNOME  uses  a  collection  of /ules  one  for  ea^ 
stereotype  related  to  the  user  expertise  levels.  For  example,  the  rule  for  CS2-STUDEN 
is:  if  the  user  is  a  CS2-STUDENT,  the  the  user  is  LIKELY  to  be  a  BEGINNER. 

Query-Reply  deductions  are  made  after  the  system  asks  whether  or  not  the  user 
knows  some  fact.  The  user’s  answer  usually  provides  information  about  whether  or  not 
the  user  knows  the  fact.  For  example,  if  a  system  were  to  ask  the  user,  “Do  you  know 
the  rep  command?”  and  the  user  answers  “Yes,”  then  the  system  can  infer  A^t  the  user 
knows  the  rep  command.  This  type  of  deduction  has  not  been  implemented  in  KNOME, 
since  the  current  version  of  UC  does  not  ask  the  user  whether  the  user  knows  particular 

facts. 
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No-Clarify  deductions  show  how  a  system  might  obtain  information  based  on  what 
the  user  does  not  say.  If  the  system  uses  some  terminology  that  the  system  is  not  sure  of 
the  user  knows,  then  the  system  can  infer  that  the  user  does  know  this  terminology  pro¬ 
vided  that  the  user  does  not  ask  for  a  clarification  and  the  meaning  of  the  terminology  is 
not  evident  from  the  context.  Such  deductions  are  more  complex  than  the  previous  ones, 
since  they  require  that  the  system  keep  track  of  the  conversation.  This  type  of  deduction 
has  not  been  implemented  in  KNOME,  since  UC  tries  to  avoid  the  use  of  terminology 
unfamiliar  to  the  user. 

In  KNOME,  deductions  are  made  using  a  rule-based  system.  The  actual  rules  were 
shown  in  Table  2.2,  with  the  exception  of  the  Background  type  of  inference.  The  Back¬ 
ground  type  inference  is  actually  implemented  by  a  collection  of  rules.  For  every  type 
of  user  background  that  gives  some  clue  about  the  user’s  level  of  expertise  in  using 
UNIX,  there  is  a  rule.  Since  there  are  potentially  many  types  of  user  backgrounds  that 
are  relevant,  there  will  be  a  correspon^ng  number  of  such  rules.  For  example,  if  the 
user  is  a  CS2  student,  then  that  is  a  relevant  piece  of  background  information  which  pro¬ 
vides  some  clue  about  user’s  level  of  expertise  in  using  UNIX.  On  the  other  hand,  the 
fact  that  the  user  is  a  scuba  diver,  likes  blueberry  pies,  or  is  a  bachelor  are  irrelevant. 
The  particular  Background  rules  that  have  been  implemented  in  KNOME  are  shown  in 
Table  2.3,  which  also  lists  the  auxiliary  inferences  which  support  the  major  inferences 
that  were  shown  in  Table  2.2. 


Such  rules  are  implemented  using  ifdetected  daemons  (see  Chapter  VI),  which  are 
daemons  that  detect  specific  configurations  of  knowledge  in  UC’s  KODIAK  knowledge 
bases.  For  example,  the  first  rule  shown  above  would  normally  fire  after  PAGAN  has 
inferred  that  the  user  wants  to  know  something.  Then  the  action  part  of  the  mle  allows 
KNOME  to  infer  that  the  user  does  not  know  some  fact. 
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These  classes  of  deductions  were  found  to  be  important  in  the  domain  of  a  natural 
language  consultation  system.  Other  domains  may  provide  other  clues  as  to  what  a  user 
knows.  For  example,  in  a  domain  where  the  user  provides  speech  input,  a  system  may  be 
able  to  make  deductions  about  the  user’s  knowledge  when  the  user  mispronounces  techn¬ 
ical  words. 

3.4.  Combining  Evidence 


After  collecting  evidence  that  the  user  does  or  does  not  know  certain  facts,  the  sys¬ 
tem  must  combine  the  evidence  to  determine  the  user’s  level  of  expertise.  Facts  are  par¬ 
ticular  pieces  of  information  about  what  the  user  does  or  does  not  know  as  described  in 
the  previous  section.  Note  that  a  single  user  statement  or  query  may  produce  several 
facts.  Each  unique  fact  is  treated  equally  in  determining  the  user’s  level  of  expertise. 
When  KNOME  deduces  that  the  user  does  or  does  not  know  something  more  than  once 
(perhaps  from  different  user  statements),  only  the  first  such  fact  is  used  in  deducing  the 
user’s  level  of  expertise.  The  rest  only  reconfirm  the  first  fact,  so  they  do  not  contribute 
to  determining  the  user’s  level  of  expertise. 

At  the  start  of  a  session,  KNOME  has  very  little  idea  about  the  level  of  expertise  of 
Lhe  user,  KNOME’ s  beliefs  about  the  user’s  level  is  encoded  as  ratings  of  the  likelihood 
that  the  user  is  a  member  of  a  candidate  stereotype  category.  As  evidence  is  gathered 
during  the  dialog,  KNOME  continuously  adjusts  its  ratings  concerning  the  likelihood  that 
the  user  might  be  a  member  of  any  particular  stereotype.  Eventually,  KNOME  gathers 
enough  evidence  to  peg  the  expertise  level  of  the  user.  Typically,  this  takes  ateut  three 
interchanges.  After  making  this  decision,  KNOME  does  not  change  its  estimation  of  the 
user’s  level.  This  works  well  in  UC  where  typical  sessions  are  short  and  it  is  advanta¬ 
geous  to  quickly  guess  the  user’s  level  of  expertise.  A  more  flexible  approach  is  to  keep 
a  running  account  of  likelihoods  as  in  SC-UM  ([Nessen  1986]),  a  user  modeling  system 
that  is  based  on  the  methodology  demonstrated  in  KNOME.  However,  a  system  that 
does  not  commit  to  a  particular  interpretation  of  the  user’s  level  of  expertise  cannot  avoid 
the  need  to  store  information  that  can  be  predicted  from  the  user  s  stereotype.  This 
becomes  inefficient  as  more  is  learned  about  the  user. 

There  are  two  types  of  conclusions  that  may  be  drawn  from  any  particular  fact 
about  what  the  user  knows  or  does  not  know.  First,  the  evidence  may  be  enough  to  elim¬ 
inate  some  stereotypes  from  consideration.  An  example  is  when  the  user  does  not  know 
a  simple  fact  such  as  the  rm  or  Is  commands.  In  these  cases,  KNOME  can  rule  out  the 
possibility  that  the  user  may  be  an  intermediate  or  an  expert,  since  all  intermediates  and 
experts  know  all  simple  facts  (see  Table  2.1).  So,  if  the  user  does  not  know  a  simple 
command  like  rm  or  Is,  then  the  user  could  not  possibly  be  more  advanced  than  a 

beginner. 

Even  when  the  evidence  is  not  enough  to  rule  out  a  category,  the  system  can  still 
infer  that  the  category  is  either  more  likely  or  less  likely.  KNOME  does  this  by  increas¬ 
ing  or  decreasing  the  likelihood  rating  of  candidate  categories. 

Likelihood  ratings  are  combined  using  the  following  linear  scale:  FALSE,  VERY- 
UNLIKELY  UNLIKELY,  SOMEWHAT-UNLIKELY,  UNCERTAIN,  SOMEWHAT- 
LIKELY,  LIKELY,  VERY-LIKELY,  TRUE.  The  UNCERTAIN  rating  is  neutral.  It 
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implies  that  the  system  does  not  believe  that  membership  in  that  category  is  either  likely 
or  unlikely.  Likelihood  ratings  combine  linearly  according  to  the  scale.  For  example,  a 
rating  of  LIKELY  when  combined  with  another  LIKELY  rating  produces  a  TRUE  rating. 
Also  a  SOMEWHAT-LIKELY  rating  combined  with  a  VERY-UNLIKELY  rating  pro¬ 
duces  an  UNLIKELY  rating. 

To  see  why  KNOME  might  change  a  likelihood  rating,  consider  what  happens  when 
KNOME  determines  that  a  user  does  not  know  some  mundane  level  fact.  In  this  case, 
KNOME  infers  that  the  user  cannot  be  an  expert,  since  experts  know  all  mundane  facts. 
Also,  KNOME  considers  it  somewhat  less  likely  that  the  user  might  be  an  intermediate, 
since  intermediates  know  most  mundane  level  facts.  Similarly,  the  user  is  considered 
somewhat  more  likely  to  be  a  beginner,  since  beginners  know  a  few  mundane  facts. 
Finally,  since  the  stereotypical  novice  does  not  know  any  mundane  facts,  the  user  is  con¬ 
sidered  more  likely  to  be  a  novice. 

Table  2.4  shows  the  basis  for  these  deductions.  Given  that  a  user  does  or  does  not 
know  a  fact  of  some  difficulty  level,  and  given  that  a  particular  user  stereotype  knows 
none/afew/most/all  of  the  facts  of  that  difficulty  level,  then  KNOME  can  deduce  that  the 
user  belongs  to  that  stereotype  with  the  additional  likelihood  shown  in  Table  2.4. 


Stereotype 

knows 

Difficulty 

Level 

Likelihood  (user  6  stereotype) 

user  does 
know  fact 

user  does  not 
know  fact 

NONE 

FALSE 

LIKELY 

AFEW 

SOMEWHAT-UNLIKELY 

SOMEWHAT-LIKELY 

MOST 

SOMEWHAT-LIKELY 

SOMEWHAT-UNLIKELY 

ALL 

LIKELY 

FALSE 

Table  2.4.  Deductions  when  user  does  (not)  know  some  fact. 

Combining  Table  2.4  with  Table  2.1,  yields  Tables  2.5  and  2.6.  Given  the  particu¬ 
lar  stereotypes  used  in  KNOME,  these  two  tables  show  the  deductions  that  are  made 
when  KNOME  determines  that  a  user  does  (Table  2.5)  or  does  not  (Table  2.6)  some  fact 
that  has  the  difficulty  level  indicated.  Deductions  consist  of  eliminating  categories 
(FALSE)  or  increasing/decreasing  the  likelihood  ratings  of  categories.  Since  these  two 
Tables  are  easily  derivable  from  the  previous  two,  KNOME  does  not  actually  store  the 
information  of  these  two  Tables  internally.  Table  2.1  is  represented  declaratively  as  a 
KODIAK  network  that  is  accessible  to  the  rest  of  UC.  Only  Table  2.4  is  stored  internally 
in  KNOME.  This  Table  is  used  when  needed  to  derive  the  likelihood  rating  differences 
shown  in  Tables  2.5  and  2.6. 
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User 

Stereotype 

Difficulty  Level  of  Fact 

simple 

mundane 

esoteric 

novice 

SOMEWHAT- 

UNLIKELY 

FALSE 

FALSE 

FALSE 

beginner 

SOMEWHAT- 

LIKELY 

SOMEWHAT- 

UNLIKELY 

FALSE 

— 

intermediate 

LIKELY 

SOMEWHAT- 

LIKELY 

SOMEWHAT- 

UNLIKELY 

— 

expert 

LIKELY 

LIKELY 

SOMEWHAT- 

LIKELY 

— 

Table  2.5.  Deduction  when  user  knows  some  fact. 


User 

Stereotype 

Difficulty  Level  of  Fact 

simple 

mundane 

complex 

esoteric 

novice 

SOMEWHAT- 

LIKELY 

LIKELY 

LIKELY 

SOMEWHAT- 

LIKELY 

beginner 

SOMEWHAT- 

UNLIKELY 

SOMEWHAT- 

LIKELY 

LIKELY 

— 

intermediate 

FALSE 

SOMEWHAT- 

UNLIKELY 

SOMEWHAT- 

LIKELY 

— 

expert 

FALSE 

FALSE 

SOMEWHAT- 

UNLIKELY 

— 

Table  2.6.  Deduction  when  user  does  not  know  some  fact. 


When  the  likelihood  rating  of  a  stereotype  reaches  TRUE,  it  is  selected  as  the  user  s 
category  The  user’s  category  can  also  be  deduced  by  elimination.  Candidate  stereo¬ 
types  are  eUminated  when  their  likelihood  drops  to  FALSE.  When  all  but  one  candidate 
have  been  eliminated,  the  remaining  candidate  is  selected.  During  the  period  before  the 
final  decision,  KNOME  works  under  the  provisional  assumption  that  the  user  belongs  to 
the  category  with  the  highest  current  likelihood.  In  the  case  of  a  tie  (i.  e.  when  there  are 
two  or  more  candidate  categories  with  the  same  highest  likelihood  rating),  the  lower 
level  of  expertise  is  chosen  to  represent  the  user  temporarily.  Using  the  lower  level  helps 
prevent  KNOME  from  overestimating  the  user  before  KNOME  is  sure  about  the  user’s 
level  of  expertise.  Underestimating  the  user’s  level  may  result  in  more  verbose  descrip¬ 
tions,  but  does  not  lead  KNOME  to  leave  out  information  that  the  user  may  not  know. 
Also,'  inferences  that  are  made  based  on  these  provisional  stereotype  assumptions  are 


marked  as  having  greater  uncertainty. 

3.5.  Examples 

To  see  how  KNOME  deduces  a  user’s  level  of  expertise,  consider  the  following 
traces  from  the  UC  sessions  shown  in  Figures  2.5  and  2.6.  At  the  start  of  either  session, 
UC  does  not  have  any  information  about  either  user.  In  such  cases,  UC  starts  with  a 
slight  bias  toward  believing  that  the  user  is  a  beginner,  because  more  UC  users  tend  to  be 
beginners.  Hence  the  likelihood  rating  for  the  user  being  a  beginner  is  SOMEWHAT- 
LIKELY,  whereas  the  likelihood  ratings  for  the  user  being  a  novice,  intermediate  or 
expert  are  all  UNCERTAIN  (the  neutral  likelihood  rating). 

In  Figure  2.5,  KNOME  deduces  that  the  user  is  a  novice,  because  the  user  does  not 
know  either  the  more  or  Ipr  commands,  which  are  both  simple  commands,  nor  the  rwho 
command,  which  is  of  mundane  difficulty.  When  KNOME  first  deduces  that  the  user 
does  not  know  the  more  command,  KNOME  can  draw  a  number  of  inferences  based  on 
the  fact  that  the  user  does  not  know  a  simple  command.  Since  experts  and  intermediates 
know  ail  simple  commands  (see  Table  2.1),  KNOME  rules  out  the  possibility  that  the 
user  might  be  an  intermediate  or  an  expert.  Also,  since  beginners  know  most  simple 
facts,  KNOME  lowers  the  likelihood  rating  for  the  user  being  a  beginner  firom 
SOMEWHAT-LIKELY  to  UNCERTAIN.  Likewise,  since  novices  know  only  a  few 
simple  facts,  KNOME  raises  the  likelihood  rating  for  the  user  being  a  novice  to 
SOMEWHAT-LIKELY. 

When  KNOME  next  determines  that  the  user  does  not  know  the  simple  command, 
Ipr,  KNOME  makes  additional  inferences.  KNOME  raises  the  likelihood  rating  of  the 
user  as  a  novice  to  LIKELY  and  lowers  the  likelihood  rating  of  the  user  as  a  beginner  to 
SOMEWHAT-UNLIKELY.  Finally  when  KNOME  finds  that  the  user  does  not  know  the 
mundane  command  rwho,  the  likelihood  rating  for  the  user  being  a  novice  rises  from 
LIKELY  to  TRUE.  TRUE  is  the  threshold  (nothing  can  have  a  higher  likelihood  than 
TRUE),  so  KNOME  concludes  that  this  user  is  a  novice. 


Welcoiae  to  UC  (Unix  Consultant)  version  3.23 
To  a  '#'  pron^st,  please  type  in  your  cjuestions 
about  the  UNIX  file  system  in  English. 

To  leave,  just  type  ' "D'  or  ' (exit) ' . 

Hi. 

How  can  I  help  you? 

#  What  will  display  a  file  on  my  terminal? 

KNOME:  Asserting  *USER*  does  not  know  ACTION12? 

KNOME:  Asserting  *USER*  does  not  know  PLArJFOR40 

KNOME:  Asserting  *USER*  does  not  know  UNIX-MORE-COMMANDO 
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KNOME : 

KNOME: 

KNOME; 

KNOME: 

KNOME: 

KNOME: 


Since  UNIX-MORE -COMMANDO  is  a  UNIX-MORE-COMMAN-D, 

asserting  *USER*  does  not  know  unix-more-command 

UNIX-MORE-COMMAND  has  difficulty  SIMPLE,  so  deducing: 

ruling  out  *USER*  =  INTERMEDIATE 

ruling  out  *USER*  =  EXPERT 

*USER*  is  SOMEWHAT-LIKELY  to  be  NOVICE 

=>  likelihood {*USER*  =  NOVICE)  =  SOMEWHAT-LIKELY 

*USER*  is  SOMEWHAT -UNLIKELY  to  be  BEGINNER 

=>  likelihood (*USER*  =  BEGINNER)  =  UNCERTAIN 


Use  more. 
For  example. 


to  display  the  file  named  foo,  type  'more  foo' 


#  How  can  I  print  a  file  on  the  lineprinter? 


KNOME: 

KNOME: 

KNOME: 

KNOME: 

KNOME: 


Asserting  *USER*  does  not  know  UNIX-DLPR-COMMANDO 
Since  UNIX-DLPR-COMMANDO  is  a  UNIX-DLPR-COMMAND, 
asserting  *USER*  does  not  know  UNIX-DLPR-COMMAND 
UNIX-DLPR-COMMAND  has  difficulty  SIMPLE,  SO  deducing 
*USER*  is  SOMEWHAT— LIKELY  to  be  NOVICE 
=>  likelihood {*USER*  =  NOVICE)  =  LIKELY 
*USER*  is  SOMEWHAT-UNLIKELY  to  be  BEGINNER 

1 -i  Volihood  ( *USEP  *  =  BEGINNER)  =  SOMEWHAT-UNLIKELY 


Use  Ipr. 

For  example,  to  print  the  file  named  foo,  type 


'Ipr  foo' . 


#  What  does  rwho  do? 


KNOME;  Asserting  *USER*  does  not  know  STATEll? 


KNOME:  Asserting  ‘USER*  does  not  know  HAS-EFFECT23 


KNOME : 
KNOME: 

KNOME : 
KNOME: 


Asserting  ‘USER*  does  not  know  UNIX-RWHO-COMMANDO 
Since  UNIX-RWHO-COMMANDO  is  a  UNIX-RWHO-COMMAND, 
asserting  ‘USER*  does  not  know  UNIX-RWHO-COMMAND 
UNIX-RWHO-COMMAND  has  difficulty  MUNDANE,  so  deducing, 
asserting  ‘USER*  =  NOVICE 


rwho  is  used  to  list  all  users  on  the  network,  list  their  tty, 
and  list  their  login  time. 


Figure  2.5.  UC  session  with  an  novice. 


In  Fieure  2.6,  KNOME  deduces  that  the  user  is  an  intermediate.  Fust,  KNOME 
deduces  that  the  user  knows  what  an  inode  is,  since  the  user  mentions  the  mode  of  a 
fik”  Since  knowing  about  inodes  is  a  complex  fact,  KNOME  is  able  to  el.mnate  the 
novice  and  beginner  categories  as  possibiUties.  KNOME  also  lowers  the  likelihood  rat- 
tag  of  th^  user  as  an  intet^ediate  and  raises  the  likelihood  rating  of  the  user  as  an  expert. 


r 
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However,  these  changes  in  likelihood  ratings  are  canceled  out  by  KNOME  s  deduction 
from  the  same  user  query  that  the  user  does  not  know  the  Is  -i  command,  which  is  of 
complex  difficulty.  Next,  KNOME  deduces  that  the  user  does  not  know  the  rw ho  com¬ 
mand  which  is  of  mundane  difficulty.  This  allows  KNOME  to  eliminate  the  possibility 
that  the  user  might  be  an  expert,  leaving  KNOME  to  conclude  that  the  user  is  an  inter¬ 
mediate,  since  that  is  the  only  possibility  left. 


Welcome  to  UC  (Unix  Consultant)  version  3.23 
To  a  prompt,  please  type  in  your  questions 

about  the  UNIX  file  system  in  English. 

To  leave,  just  type  ' "D'  or  ' (exit) ' . 


Hi. 

How  can  I  help  you? 

#  Can  you  tell  me  how  to  find  out  the  inode  of  a  file? 


KNOME: 

xvxVv_/i'xi-i  • 


KNOME: 

KNOME: 

KNOME: 

KNOME: 

KNOME: 


Asserting  *USER*  knows  INODEl 

Since  INODEl  is  a  INODE, 

asserting  *USER*  knows  INODE 

INODE  has  difficulty  COMPLEX,  so  deducing : 

ruling  out  *USER*  =  NOVICE 

ruling  out  *USER*  —  BEGINNER 

*USER*  is  SOMEWHAT-UNLIKELY  to  be  INTERMEDIATE 
»>  likelihood (*USER*  =  INTERMEDIATE)  =  SOMEWHAT-UNLIKELY 
*USER*  is  SOMEWHAT-LIKELY  to  be  EXPERT 
=>  likelihood (*USER*  =  EXPERT)  =  SOMEWHAT-LIKELY 


V 


KNOME:  Asserting  *USER*  does  not  know  ACTION15? 

KNOME:  Asserting  *USER*  does  not  know  PLANFOR390 

KNOME:  Asserting  *USER*  does  not  know  UNIX-LS-i  COMMANDO 
KNOME:  Since  UNIX-LS-i-COMMANDO  is  a  UNIX-LS-i-COMMAND, 
asserting  *USER*  does  not  know  UNIX-LS-i-COMMAND 
KNOME:  UNIX-LS-i-COMMAND  has  difficulty  COMPLEX,  so  deducing: 
KNOME:  *USER*  is  SOMEWHAT-LIKELY  to  be  INTERMEDIATE 

=>  likelihood (*USER*  =  INTERMEDIATE)  =  UNCERTAIN 
KNOME:  *USER*  is  SOMEWHAT-UNLIKELY  to  be  EXPERT 

=>  likelihood (*USER*  =  EXPERT)  =  UNCERTAIN 


Type  'Is  -i' . 


#  What  does  rwho  do? 


KNOME : 
KNOME ; 


Asserting  *USER*  does  not  know  UNIX-RWHO-COMMANDO 
Since  UNIX-RWHO-COMMANDO  is  a  UNIX-RWHO-COMMAND , 
asserting  *USER*  does  not  know  UNIX-RWHO-COMMAND 
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KNOME:  UNIX-RWHO-COMMAND  has  difficulty  MUNDANE,  so  deducing: 

KNOME  •  rulincf  out  *USER*  =  EXPERT 

KNOME.  ruling  o  asserting  *USER*  =  INTERMEDIATE 

KNOME:  only  one  candidate  left,  so  asserting 

rwho  is  like  who,  except  rwho  is  for  all  users  on  the  network. 


Figure  2.6.  UC  session  with  an  intermediate. 


Even  before  KNOME  has  completely  determined  the  expertise  level  of  the  user, 
KNOME’s  partial  user  model  is  stiU  useful  to  the  other  components  of  UC.  In  Ae  dialog 
with  the  novice,  UC  chooses  to  provide  the  user  with  examples  of  command-formats 
based  on  KNOME’s  initial  deduction  that  the  user  is  SOMEWHAT-LIKELY  to  be  a 
novice.  On  the  other  hand,  UC  does  not  provide  examples  of  simple  conmand-formats 
to  the  intermediate  user  who  presumably  would  already  know  such  simple  formats.  Also, 
UC  is  able  to  use  a  simile  to  explain  to  the  intermediate  user  the  rwho  command  in  terms 
of  the  who  command.  The  novice  user  was  given  a  complete  explanation  of  rwho  since 
KNOME  believed  that  the  user  would  not  know  the  who  command  and  so  would  not 

understand  the  simile. 


4.  Modeling  UC’s  Knowledge 

Besides  modeling  what  users  know,  KNOME  also  models  what  UC  itself  knows. 
Such  a  model  allows  KNOME  to  differentiate  between  cases  where  UC  lacks  knowledge 
and  where  the  user  has  a  misconception  (see  Chapter  III,  Section  4). 

4.1.  Open  vs.  Closed  World  Models 


An  important  problem  in  AI  knowledge  bases  is  to  define  the  limitations  of  the 
knowledge  base.  One  solution  is  to  use  a  closed  world  model,  which  states  that  the 
knowledge  base  knows  everything  (see  [Reiter,  1978]).  In  a  closed  world  rnodel,  any¬ 
thing  that  is  neither  in  the  knowledge  base  nor  deducible  from  the  knowledge  base  is 
deemed  false.  Such  a  model  works  only  for  completely  self-contained  micro-worlds  sue 
as  airline  reservation  systems  that  know  all  airline  flights.  For  real  world  applications,  a 
closed  world  model  is  untenable,  since  real  world  knowledge  bases  cannot  toow  every¬ 
thing  even  in  just  their  own  area  of  expertise.  So  a  system  with  a  closed  model  would  be 
prone  to  giving  out  false  information  such  as  claiming  that  objects  that  the  system  did  not 
happen  to  know  about  do  not  exist,  claiming  that  actions  that  the  system  could  not  gure 

out  cannot  be  done,  etc. 

The  other  extreme  is  an  open  world  model,  which  states  that  anything  that  is  neither 
in  the  knowledge  base  nor  direcUy  deducible  from  the  knowledge  base  is  not  known. 
This  model  has  a  significant  problem  with  ruling  out  things  that  do  not  exisn  For  exam¬ 
ple,  a  knowledge  base  might  list  all  the  participants  in  any  panicular  relation.  Using  a 
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closed  world  model,  the  system  would  know  that  these  are  the  only  participimts  of  that 
relation  However,  in  an  open  world  model,  the  system  cannot  rule  out  that  there  nug  t 
not  be  other  participants  unless  the  knowledge  base  explicitly  encodes  for  all  other  possi¬ 
ble  participants  that  they  do  not  participate  in  that  relation.  Since  there  are  usually  many 
more  such  negative  facts  than  positive  facts,  encoding  such  facts  in  a  knowledge  base  is 

extremely  inefficient. 

Neither  model  is  quite  adequate.  A  closed  world  model  allows  a  system  to  rule  out 
spurious  hypotheses  easily,  but  is  prone  to  ruling  out  true  facts  that  were  not  in  the 
Imowledge  base.  An  open  world  model  allows  the  system  to  be  non-committal  about 
hypotheses  that  are  not  covered  by  its  knowledge  base,  but  does  not  all^  it  to  rule  out 
spinous  hypotheses  when  the  system  does  have  complete  information.  The  ideal  system 
needs  to  combine  the  best  of  both  models.  It  needs  to  be  assertive  in  ruling  out  spurious 
hypotheses  when  the  system  does  have  complete  information,  yet  remain  non-coiimittal 
when  it  does  not  have  complete  information.  To  do  this,  a  system  needs  to  know  the  lim¬ 
itations  of  its  own  knowledge. 

4.2.  Meta-Knowledge 

UC  uses  an  open  world  model  augmented  by  knowledge  about  the  coverage  limita¬ 
tions  of  the  knowledge  base.  By  using  an  open  world  model,  UC  is  a,bie  to  remam  non¬ 
committal  about  information  that  is  not  in  its  knowledge  base.  This  allows  UC  to  profess 
ignorance  about  things  outside  its  area  of  expertise.  On  the 

have  complete  information  about  an  area,  this  is  explicitly  encod^  in  s  model 

of  UC’s  knowledge.  In  a  sense,  this  is  a  model  of  what  UC  itself  knows.  Such 

knowledge  is  called  meta-knowledge . 

The  term  meta- knowledge  was  previously  used  for  AI  knowledge  bases  by  [Barr, 
19771  and  [Davis  and  Buchanan,  1977).  [Barr,  1977)  argues  that  AI  knowledge  bases 
need  meta-knowledge,  i.  e.  the  system’s  knowledge  about  “the  extent  and  limt  of  avail¬ 
able  knowledge,  what  facts  are  relevant  in  a  given  situation,  how  dependable  they  are, 
and  how  they  are  to  be  used.”  [Davis  and  Buchanan,  1977]  describes  meta-knowledge  in 
the  TEIRESIAS  system  and  its  use  in  knowledge  acquisition  and  in  selecting  which  ru  es 
to  try  applying  first  through  the  use  of  meta-rules.  [Smith  and  Genesereth,  1983]  use 
meta-level  reasoning  to  find  all  of  the  solutions  to  a  problem.  Although  they  use  a  closed 
world  assumption,  they  suggest  that  other  systems  for  which  the  closed  world  assumption 
is  not  valid  can  encode  limits  on  the  number  of  solutions  and  use  these  limits  to  cut  o 
inference.  Such  limits  can  be  considered  a  type  of  meta-knowledge. 

In  KNOME,  meta-knowledge  is  not  primarily  used  for  the  same  purposes  as  in 
TEIRESIAS;  rather  it  is  primarily  used  in  dealing  with  user  misconcepPons.  So 
KNOME’s  rneta-knowledge  describes  the  coverage  limitations  of  UC’s  knowledge  base. 
Chapter  HI,  Section  4  describes  how  user  misconceptions  are  detected  and  how  meta¬ 
knowledge  is  used  in  correcting  the  user’s  misconceptions. 
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4.3.  Representation  of  Meta-Knowledge 


Meta-knowledge  in  KNOME  is  represented  explicidy  as  a  collection  of  KODIAK 
statements  about  what  UC  knows.  Examples  of  meta-knowledge  include  the  fact  that  UC 
knows  that  it  knows  all  file  manipulation  commands  and  the  fact  that  UC  knows  all  pos¬ 
sible  side  effects  for  all  known  simple  commands,  and  most  known  mundane  commands 
and  a  few  known  complex  commands.  The  fact  that  UC  does  not  know  all  of  the  side 
effects  for  known  commands  is  due  to  not  enough  programming  and  the  knowledge  limi¬ 
tations  of  the  UC’s  programmers  rather  than  any  inherent  limitation  of  UC. 

Figure  2.7  shows  the  representation  of  KNOME’s  meta-knowledge  about  simple 
commands.  KNOWl  states  that  UC  knows  all  of  the  effects  of  simple  commands,  and 
KNOW2  represents  the  fact  that  UC  knows  all  of  the  options  of  simple  commands. 


Figure  2.7.  KODIAK  representation  of  some  of  UC’s  meta-knowledge. 

Besides  the  explicit  meta-knowledge  modeled  by  KNOME,  UC  also  has  meta¬ 
knowledge  that  is  represented  implicitly  within  the  KODIAK  representation  language. 
For  example,  any  aspectual  of  a  relation  can  be  constrained  to  be  filled  by  only  certain 
classes  of  objects.  This  effectively  constrains  the  way  in  which  different  objects  may  be 
related  to  other  objects  in  KODIAK.  Of  course,  these  constraints  are  sometimes  violated 
when  users  speak  metaphorically.  [Martin,  1987]  describes  how  such  metaphors  and 
analogies  can  be  handled  in  the  UNIX  domain. 


5.  Conclusion 


5.1.  Summary 

The  user  modeling  system  of  KNOME  is  extremely  simple,  yet  it  provides  enough 
functionality  for  the  needs  of  UC.  KNOME  can  infer  what  the  user  knows  from  a  consu- 
lation  dialog  with  the  user.  Based  on  only  a  few  such  facts  about  what  a  user  does  or 
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does  not  know,  KNOME  can  also  predict  many  other  default  facts  about  what  the  user 
might  or  might  not  know.  KNOME’s  stereotypes  serve  to  efficiently 
inferences  that  commonly  co-occur.  Using  only  a  few  such  stereot^es,  KNOME  is  ab  e 
to  provide  enough  differentiation  among  potential  users  so  that  UC  can  use  these  di  e  - 
ences  in  answer  expression,  goal  analysis,  and  detection  of  situanons  when  the  user  lacks 
knowledge  or  has  misconceptions.  The  double-stereotype  system  is  not  only  space 
Xient,  but  also  allows  easy  addition  of  knowledge  to  KNOME.  When  a  new  fact  is 
added  to  UC,  the  knowledge  engineer  needs  only  to  classify  the  new  fact  according  to  its 

difficulty  level. 

Although  no  attempt  has  been  made  yet  to  apply  the  methodology  to  other  areas,  it 
would  seem  that  many  of  the  techniques  should  transfer  well.  Stereotype  categones  are 
used  in  UC  in  similar  fashion  to  the  way  humans  use  categones  that  reference 
points  for  reasoning  about  individual  members  (see  [Rosch,  1977],  [Rosch,  1978],  and 
IRosch  1983]).  Thus  stereotypes  should  be  useful  for  approximate  reasonmg  wherever 
human  categorization  has  proven  to  be  useful.  The  double- stereotype  system  extends  the 
use  of  computer  stereotype  categories  to  cover  more  of  human  categonzation,  that  is  to 
include  categories  for  knowledge  as  well  as  categones/stereotypes  for  people/users.  The 
double-stereotype  system  can  be  applied  straightforwardly  to  other  domains  where  a 
computer  system  needs  to  model  the  relation  between  different  classes  of  users  and  dif¬ 
ferent  classes  of  information.  In  cases  where  the  user  population  is  homogeneous  or 
where  the  information  is  homogeneous,  then  a  double-stereotypes  system  would  not  be 

applicable. 

The  methodology  used  to  deduce  the  user’s  stereotype  in  KNOME  tr^sfers  in  two 
ways  to  other  domains.  First,  the  method  used  to  infer  individual  facts  about  what  the 
user  knows  is  applicable  to  any  natural  language  system  that  needs  to  infer  facts  about 
the  user’s  knowledge  based  on  what  the  user  says.  On  the  other  h^d,  the  methodology 
used  to  combine  such  evidence  is  highly  dependent  on  a  double- stereotype  system. 
However  it  can  be  used  in  any  double-stereotype  system  where  the  system  can  deduce 
particular  relations  between  the  user’s  stereotype  and  the  modeled  information. 

5.2.  Problems 

Currently  KNOME  does  not  address  the  problem  of  whether  the  user  knows  some¬ 
thing  after  Uc’has  informed  the  user.  The  difficulty  is  that  the  user  may  not  understand 
the  system’s  presentation,  in  which  case  the  user  modeling  system  should  not  infer  that 
the  user  knows  the  new  information.  A  drawback  of  systems  linuted  to  natural  language 
interactions  is  that  these  systems  cannot  watch  the  user’s  reactions  to  deduce  whether  or 
not  the  user  is  having  trouble  understanding  the  system’s  presentation.  Human  consul¬ 
tants  are  able  to  switch  explanation  strategies  midway  through  a  presentation  when  they 
notice  their  clients’  facial  expressions  showing  confusion.  A  computer  consultant  would 
have  to  wait  for  the  user  to  respond  with  language  in  order  to  get  fe^back.  In  such 
cases,  the  best  that  a  user  modeling  system  can  do  may  be  to  assume  that  the  user  has 
understood  (perhaps  with  a  lower  certainty  factor),  until  the  modeler  gets  evidence  to  he 
contrary  Then,  if  the  user  does  not  ask  for  a  clanfication  in  the  next  exchange,  the 
modeler  can  increase  the  cenainty  of  its  belief  that  the  user  has  indeed  understood. 
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Another  deficiency  in  KNOME  is  that  it  does  not  contain  very  many  ^ 

for  inferring  what  specific  facts  a  user  might  know  based  on  other  specific  facts  that  *e 
user  knows^  For  exSiple,  if  a  user  knows  the  rwho  command,  then  it  is  very  likely  tha 
diTuser  will  also  know  the  who  command.  KNOME  has  avoided  these  t^s  of  explicit 
rules  in  favor  of  the  more  efficient,  though  less  specific  mechanism  of 
The  double  stereotypes  aUow  KNOME  to  combine  a  small  number  of  explicit  facts  to 
first  inter  the  user's  level  of  expertise  and  from  this,  the  user's 

Other  facts  Although  this  powerful  general  mechanism  works  weU,  there  ^e  sull  cases 
wtS  explicit  rules  wm  give  more  specific  information  ato  what  a  user  taows 
higher  degree  of  certainty.  The  GUMS  general  user  modeling  shell  ([Finm,  19871) 

makes  good  use  of  these  explicit  rules. 

A  possible  deficiency  with  KNOME's  method  of  combining  '-^dence  js  that 
KNOME  marks  the  user  as  belonging  to  a  particular  stereotype  after  only  “  short  “me 
(tvpically  -3  Interchanges).  After  this,  KNOME  does  not  alter  its  concepnon  of  the 
uS’s  level  of  expertise.  This  is  reasonable  in  the  UC  domam,  because  UC  sMsions  m 
typically  short.  However,  this  would  not  be  acceptable  for  longer  term  user  models^  K 
svLm  Leds  to  keep  track  of  a  user's  level  of  expertise  over  penods  long  enough  that 
*ru“"s  expertise  Ly  increase  appreciably,  then  the  system  needs  to  be  able  to  change 
t  “a  “^"fe  user's  level  of  expertise.  This  process  is  easier  than  one  might  sup- 
p'^seTstace'a  user's  level  of  expertise  tends  to  grow  monotonically  (tt  seems  reasonable 
to  ignore  the  phenomenon  of  forgetting). 

Cuirently,  KNOME  only  has  a  single  range  of  user  expertise  and  a  single  range  o 
knowlX  dlLulty,  This  is  sufficient  for  UC,  since  UC  only  covers  co"mands  related 
m  the  UNIX  file  system.  In  order  to  extend  UC  to  cover  other  areas  of  UNIX  su^  as 

using  the  Vi  or  emaos  editors,  KNOME  would  need  additional  of  muT 

levefs  and  information  difficulty  levels.  Problems  which  need  to  be  ad*essed  with  mul¬ 
tiple  ranges  include  how  the  levels  in  one  range  might  relate  to  the  leve  s  of  other  ran  es^ 
For  exSe,  a  system  may  be  able  to  predict  that  an  expert  in  using  «  is  likely  to  be  m 
expert  in  using  the  UNIX  file  system.  On  the  other  hand,  there  may  be  no  such  relations 
Jween  famifiarity  with  emaos  and  familiarity  with  the  UNIX  file  system,  since  the 
emacs  editor  is  common  to  many  other  operating  systems. 

Another  area  which  KNOME  does  not  address  completely  is  how  to  model  users  of 
other  operating  systems.  Such  users  may  be  able  to  transfer  some  amounts  of  expertise 
to  UNIX  These  users  can  benefit  from  analogies  between  UNIX  and  the  operating  sy  - 
tem  that  they  know.  On  the  other  hand,  such  users  sometimes  incomectly  apply  analogies 
and  often  mix  up  commands.  Adding  additional  stereotypes  for  such  users  would 
enhance  KNOME’s  ability  to  provide  proper  analogies  and  to  detect  improper  ana  og 
ofcXnmd  usage.  [MaLlL,  1983]  has  shown  that  one  user  modeling  system  can 
Seq3y  mode?  different  operating  systems  (UNIX,  TOPS-20,  and  VM).  However, 
no-L  has  investigated  how  knowledge  of  the  user's  expertise  m  one  “ 

another  domain  (correctly  or  incorrectly)  or  how  to  exploit  such  knowledge  (e.  g.  to  p 

vide  analogies).  . 

Other  areas  not  addressed  by  KNOME  include  applying  the  ^ 

strated  in  KNOME  for  other  purposes  such  as  selection  of  terminology  in  ge  _ 

f.  [Lehman  and  Carbonell,  1987])  The  approach  used  in  KNOME  would  also  be  usefu 
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the  selection  of  different  explanation  strategies  as  in 


the  TAILOR  system  ([Paris,  1987]). 
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Chapter  m 


Goal  Detection 

The  central  problem  in  building  an  intelligent  agent  is  how  to  detect  appropriate 
goals  for  the  agent,  goals  that  can  then  be  used  to  guide  the  agent’s  actions.  This  process 
is  called  goal  detection  ([Wilensky,  1983]). 

Although  considerable  work  has  been  done  in  the  area  of  planning,  vep.  few  plan¬ 
ning  systems  have  addressed  the  problem  of  how  to  detect  appropnate  goals  for  planning. 
In  Lost  all  planning  systems,  the  high  level  goals  are  provided  by  the  human  operators 
of  L  Dlannera.  An  exception  is  described  by  [Allen,  1979],  whose  system  simulated  a 
train  station  ticket  agent.  It  detected  goals  based  on  an  analysis  of  obstacles  to  a  use^s 
plans  By  addressing  these  obstacles,  the  system  could  volunteer  information  that  the 
Ler  would  need  to  Achieve  the  user’s  plan.  This  approach  addresses  only  a 
the  general  problem  of  goal  detection.  An  analysis  of  obstacles  to  the  user  s  plan  does 
not  Address  how  these  obstacle-related  goals  might  interact  with  the  system  s  other  goal  ^ 
Also  analyzing  obstacles  would  not  lead  a  system  to  detect  user  misconceptions  and 
detect  the  goal  of  correcting  the  misconceptions.  Even  in  terms 

information  to  the  user,  an  analysis  of  obstacles  to  a  user  s  plans  does  not  address  the 
problem  when  the  system  should  volunteer  an  alternative  plan. 

The  PANDORA  planner  ([Faletti,  1982])  also  detected  its  own  goals.  It  detected 
goals  when  actual  or  projected  states  conflicted  with  goals  or 

frames  describing  situations  were  activated.  For  example,  the  goal  of  find  out  about  the 
worid”  ™ched  .0  me  -morning”  frame,  which  meant  that  PANDO^  would  ^ 
to  read  a  newspaper  in  the  morning.  However,  except  for  ve^  simple  PAN¬ 

DORA  did  not  address  the  problem  of  when  is  it  proper  to  invoke  frames  md  their  asso- 
cialed  goals.  Also,  because  PANDORA  existed  in  a  self-contained  simulated  worid, 
did  nof  address  the  problem  of  detecting  goals  when  the  system  must  interact  with  real 

users. 

Once  an  agent  has  determined  its  goals,  then  the  relatively  better  understood  process 
of  planning  can  be  applied  to  satisfy  those  goals.  A  simple  plan  selection  and 
mechanism  for  satisfying  such  goals  is  described  in  Chapter  IV.  This  chapter  desenb 
how  goals  are  represented  in  UC  and  how  such  goals  are  detected  by  UCEgo. 


1,  Definitions  and  Classifications 

This  section  describes  the  types  of  goals  found  in  UC  and  how  they  are  ^presented 
Different  goals  are  detected  by  UCEgo  in  different  situations.  The  types  of  situations 
that  give  rise  to  new  goals  for  UC  are  classified  here,  while  later  sections  desenbe  the 
specific  goals  that  are  detected  in  each  type  of  situation. 
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1.1.  Types  of  Goals 

In  UC,  goals  are  represented  in  KODIAK  (see  Appendix  A)  using  die  R\S-GOAL 
relation,  which  has  two  aspectuals:  goal  and  planner.  That  is,  a  goal  is  modeled  as  a 
relation  between  an  individual  (planner)  and  some  state  (goal)  which  that  individual 
wishes  to  achieve.  There  is  no  absolute  category  of  goals,  since  a  state  cannot  be  said  to 
be  a  goal  unless  some  individual  can  be  said  to  have  that  goal.  This  is  not  to  say  that 
there  are  not  some  states  (e.  g.  having  lots  of  money)  that  are  habitually  thought  of  as 
being  goals.  However,  habitual  goals  encompass  only  a  fraction  of  what  is  meant  by  the 
term  goal.  Almost  any  state  can  be  a  goal  provided  only  that  some  individual  wishes  to 
achieve  that  state.  Thus  treating  goals  as  aspectuals  of  HAS-GOAL  relations  captures 
the  meaning  of  the  term  goal.  A  graphical  representation  of  the  definition  of  the  HAS- 
GOAL  relation  is  shown  in  Figure  3.1. 


Figure  3.1.  Definition  of  goals  in  UC. 

Besides  the  goal  and  planner  aspectuals,  HAS-GOAL  has  a  status  aspectual. 
This  aspectual  of  HAS-GOAL  is  actually  inherited  from  M-POSSESS  (for  mental- 
possess),  which  dominates  HAS-GOAL  as  well  as  KNOW,  BELIEVE,  and  HAS- 
INTENTION  That  is,  HAS-GOAL  is  a  kind  of  M-POSSESS  where  the  planner  is  the 
possessor  and  the  goal  is  the  possessed  object.  The  status  aspectual  describes  the 
status  of  the  relation  and  can  have  the  values  ACTIVE,  INACTIVE,  or  DONE.  An 
HAS-GOAL  with  an  ACTIVE  status  means  that  the  planner  is  currently  actively  pursu¬ 
ing  that  goal.  INACTIVE  implies  that  it  is  not  the  case  that  the  planner  currently  has  that 
goal  Note  that  this  is  not  the  same  as  saying  that  the  planner  has  the  inverse  goal.  For 
instance,  if  it  is  not  the  case  that  UC  wants  a  file  to  exist,  then  it  does  not  necessanly  fol¬ 
low  that  UC  wants  that  file  to  not  exist.  It  may  just  be  that  UC  does  not  care  whether  that 
file  exists  or  not.  The  status  DONE  implies  that  the  planner  has  already  achieved  the 
goal  The  DON"E  marker  is  usually  applied  to  ACTIVE  goals  that  become  satisfied  dur¬ 
ing  the  course  of  a  UC  session.  To  be  complete,  UC  should  have  a  full  temporal 
representation  based  on  points,  intervals,  or  some  other  formalism.  However  ^cause 
full  temporal  reasoning  was  not  found  to  be  essential  for  the  proper  operation  of  UC,  the 
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DONE  status  was  devised  as  a  simple  expedient  for  marking  goals  that  have  been 
achieved  during  a  session. 

Among  HAS-GOALs,  there  is  a  sub-class  called  UC-I^S-GOAL  where  the 
Dlanner  is  UC.  This  separation  highlights  the  importance  of  UC’s  own  gods  to  itself.  I 

between  the  goals  of  UC  and  the  goals  of  other  agents  that 

can  be  found  in  UC’s  knowledge  base. 

Other  types  of  goals  include  recurrent  goals  and  background  goals.  Recument 
goals  are  those  goals  that  recur  even  after  they  have  been  satisfied.  An  example  is  UC  s 
godoThei^ng  L  user.  Even  after  UC  has  helped  the  user  once.  UC  continues  o^  to 
Llo  the  user  (Recurrent  gods  in  UC  are  different  than  cyclic  physiologicd  gods  — 
f  g  sanation  o{  hunger,  sanation  of  thirst,  and  need  for  rest/sleep  -  because  the  cychc 
goals  are  not  constantly  active;  rather,  they  are  inactive  for  a  penod  immediately  rft 
Aeir  satisfaction.)  Recurrent  gods  are  represented  in  UC  as  simple  sequences  in  w 
Ihe  next  item  in  the  sequence  is  itself.  In  handling  goal  sequences,  UC  adopts  successive 
“rs  of  the  sequence  as  goals,  continuing  to  the  next  member  tfter  satisfying  *e 
previous  member.  By  encoding  recurrent  gods  as  self-referential  god  sequences, 
UCEgo  avoids  the  need  for  a  special  status  for  recurrent  gods. 

Background  gods  are  those  gods  that  do  not  require  immediate  attention.  Exam¬ 
ples  of  background  gods  include  gods  of  politeness  and  vanous 

([Schank  and  Abelson,  1977])  that  arise  from  the  Preservation^  7  back 

Examples  include  self-preservation  and  preservation  of  the  UNIX  system.  Since  back 
ground  gods  are  not  dedt  with  immediately,  this  creates  the  problem  of  deci^g  when  a 
Sckground  god  should  be  pushed  to  the  foreground.  This  is  equivdent  to  the  problem 
of  detecting  new  gods,  since  pushing  a  background  goal  to  the  foreground  can  be 
Sought  of  fs  having  a  new  god  to  consider.  In  UCEgo,  the  problem  of  activating  back¬ 
ed  god  is  handled  by  Ignoring  background  gods  until  UCEgo  encounters  a  situa¬ 
tion  a  plan  for  handling  the  background  god.  Once  UCEgo  detects  a  plan 

for  the  background  god,  then  the  background  goal  is  activated  and  is  treated  like  any 

other  foreground  god. 

[Wilensky,  1983]  argues  against  the  need  for  background  such  as  prese^a- 

tion  goals  Instead,  themes,  such  as  the  Preservation  theme,  would  directly  give  nse  t 
specific  goals  in  appropriate  situations.  This  scheme  would  eliminate  the  exma  inter¬ 
mediate  level  of  background  gods  between  themes  and  the  specific  gods. 

“  its  Lermediam  level  of  general  goals,  a  system  would  no.  be  able  to  abandon 
some  of  the  general  gods  of  a  theme  without  either  abandoning  the  whole  theme,  o 
adding  ad-hoc  rules  that  disable  the  detection  of  a  some  subset  of  situation  classes  in 

which  that  theme  should  detect  specific  goals.  With  intermediate 
can  easily  disable  part  of  a  theme  by  disabling  the  appropnate  intermeiate  level  goals. 
The  inteirnediate  level  gods  also  make  it  easier  for  a  system  to  reason  about  its  own  gen- 
erd  gods  (e.  g.  does  the  system  want  to  preserve  itself),  since  these  general  gods 

explicitly  represented  in  the  system. 
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1.2.  Types  of  Situations 

In  general,  an  agent  may  detect  new  goals  whenever  there  is  a  change  in  an  agent  s 
environment  or  internal  state.  Any  such  combination  of  factors  in  the  agent  s  environ¬ 
ment  and/or  in  the  agent’s  internal  state  that  leads  to  a  new  goal  for  the  agent  is  called  a 
situation  after  the  terminology  of  [Wilensky,  1983]. 

For  the  purposes  of  detecting  goals,  it  is  less  important  to  provide  a  taxonomy  of 
goals,  such  as  in  [Schank  and  Abelson,  1977]  and  [Carbonell,  1982].  Rather,  it  is  more 
important  to  catalog  the  types  of  situations  that  lead  a  planner  to  detect  new  goals.  This 
section  will  classify  the  kinds  of  situations  that  lead  UCEgo  to  detect  new  goals. 

Since  UC  is  a  computer  consultation  system,  UCEgo’s  environment  is  limited  to  a 
dialogue  with  the  user  on  the  subject  of  the  UNIX  operating  system.  So  for  UCEgo, 
situations  are  composed  of  combinations  of  UC’s  internal  state,  the  user  s  statements, 
and  information  that  might  be  derived  from  the  user’s  statements  such  as  the  user  s  plans 
and  goals  and  the  user’s  knowledge  and  beliefs.  UC’s  internal  state  includes  UC  s 
domain  knowledge,  UC’s  own  goals,  and  UC’s  themes  ([Schank  and  Abelson,  1977]). 

The  situations  that  give  rise  to  goals  in  the  UC  domain  can  be  divided  into  five  main 
situation  classes: 


1)  themes  goals 

2)  plans  sub-goals 

3)  goal  interactions  ->  meta-goals 

4)  gaps  in  the  user’s  knowledge  — >  goals 

5)  user  misconceptions  -4  goals 

Themes  can  be  considered  as  the  internal  motivations  of  an  agent;  so  they  are  a 
prime  source  of  new  goals.  Another  source  of  goals  is  the  planning  process.  As  an  agent 
plans  for  goals,  the  resulting  plans  may  produce  sub-goals  that  the  agent  will  need  to 
adopt  and  in  turn  plan  to  satisfy.  When  an  agent  has  several  goals,  these  goals  may 
interact,  giving  rise  to  a  meta-goal  ([Wilensky,  1983]),  which  is  a  goal  for  dealing  with 
the  interaction  among  other  goals. 

The  previous  three  sources  of  goals  are  universal  in  that  they  are  common  to  all 
intelligent  agents.  The  other  two  sources  of  goals  are  somewhat  more  particular  to  a  con¬ 
sulting  environment.  In  a  consulting  environment,  situations  commonly  arise  wherein 
the  state  of  the  user’s  knowledge  base  (as  deduced  by  KNOME  from  conversing  with  the 
user)  differs  from  the  consultant’s  knowledge  base.  One  kind  of  difference  is  detected 
when  the  consultant  determines  that  the  user  lacks  some  necessary  knowledge.  Another 
kind  of  difference  is  found  when  the  consultant  determines  that  the  user’s  knowledge 
base  conflicts  with  its  own  knowledge  base,  that  is,  that  the  user  has  a  misconception. 
Both  of  these  classes  of  situations  are  concerned  with  the  user’s  knowledge,  because  that 
is  the  main  task  of  a  consultant,  namely  to  impart  information  to  the  user.  In  other  types 
of  programs,  a  different  focus  may  lead  to  other  situation  classes.  The  situation  classes 
listed  above  are  described  in  greater  detail  in  the  following  sections. 
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In  UCEgo,  situation  classes  are  encoded  using  if-detecied  daemons.  Each  daemon 
is  a  tiny  inference  engine  that  detects  the  presence  of  particular  configurations  of 
KODIAK  network  in  UC’s  knowledge  base.  When  an  if-detected  daemon  detects  a 
match,  the  daemon  is  activated  and  adds  its  inference  in  the  form  of  more  KODIAK  net¬ 
work  to  UC’s  memory.  In  the  case  of  if-detected  daemons  that  are  used  for  goal  detec¬ 
tion,  the  matching  KODIAK  network  represents  a  situation  class,  and  the  inference  adds 

a  new  goal  to  UC’s  memory. 

An  example  of  an  if-detected  daemon  used  for  goal  detection  is  shown  in  Figure  3.2 
This  is  a  very  simple  daemon  that  asserts  that  in  situations  where  the  user  wants  to  exit 
(HAS-GOALl),  UCEgo  should  detect  the  goal  of  exiting  (UC-HAS-GOALl).  More 
details  on  the  implementation  of  if-detected  daemons  can  be  found  in  Chapter  VI. 


Figure  3.2.  If-detected  daemon  for  detecting  the  goal  of  exiting. 


2.  Goals  from  Themes  and  Plans 

UCEgo  has  a  number  of  themes  ([Schank  and  Abelson,  1977]),  which  give  rise  to 
goals.  These  include  life  themes  as  well  as  role  themes.  An  example  of  a  life  theme  is 
UCEgo’ s  Stay- Alive  theme.  This  theme  gives  rise  to  the  recurrent  background  goals  o 
preserving  the  UC  program  and  preserving  the  UNIX  system.  The  Stay-Alive  theme  is 
^so  an  instance  of  the  Preservation  theme  ([Wilensky,  1983]),  since  it  gives  nse  to 
preservation  goals.  An  example  of  a  role  theme  is  UCEgo’s  Consultant  role  theme.  This 
gives  rise  to  the  recurrent  goals  of  helping  the  user  and  being  polite  to  the  user.  The  goal 
of  being  polite  is  a  background  goal,  since  UCEgo  does  not  attempt  to  plan  for  it 
immediately.  On  the  other  hand,  the  goal  of  helping  the  user  is  a  foreground  goal, 
because  UC  immediately  tries  to  find  ways  to  help  the  user. 

Since  all  goals  that  arise  from  themes  are  detected  when  UC  first  starts  up,  it  might 
seem  that  attributing  these  goals  to  themes  is  extraneous.  However  themes  are  really 
quite  useful.  First  of  all,  themes  provide  relative  importance  ordenng  for  goals,  which  is 
useful  in  case  of  goal  conflicts  (see  Section  3,  Meta-Goals).  This  relative  importance  or 
goals  can  be  used  as  a  basis  for  a  more  complete  theory  for  the  calculus  of  the  value  of 
different  goals  for  an  agent.  Secondly,  they  provide  a  means  of  organizing  goals  into 
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related  groups.  For  example,  if  UC  were  to  provide  other  functions  besides  a  UNIX  Con¬ 
sultant,  then  the  goals  that  arise  from  its  Consultant  role  theme  could  be  added  when  UC 
starts  working  as  a  consultant  and  removed  when  UC  stops  working  as  a  consultant. 

The  goals  that  arise  from  themes  usually  give  rise  to  yet  more  goals,  called  sub¬ 
goals,  during  the  planning  phase  of  UCEgo.  In  fact,  all  of  UC’s  goals  can  ultimately  be 
traced  back  to  UC’s  themes,  either  directly  or  as  sub-goals  of  other  goals,  which  in  turn 
can  be  traced  back  to  UC’s  themes. 

2.1.  An  Example  Trace 

To  see  how  UCEgo  detects  goals  during  the  planning  process,  consider  a  very  sim¬ 
ple  interaction  with  UC  such  as  shown  in  Figure  3.3.  The  main  goal  that  UCEgo  detects 
in  this  interaction  is  the  goal  (UC-HAS-GOAL50)  of  having  the  user  know  how  to  delete 
a  file  (KNOW-gaO).  This  goal  leads  UCEgo  to  call  the  UNIX  domain  planner  com¬ 
ponent  of  UC  to  determine  the  answer.  Then  UCEgo  selects  the  plan  (PLANFOR56)  of 
telling  the  user  the  answer.  The  goal  of  having  the  user  know  is  actually  a  sub-goal  of 
UC’s  goal  of  helping  the  user  (UC-HAS-GOAL47),  which  arose  from  UC’s  Consultant 

role  theme. 


Welcome  to  UC  (Unix  Consultant)  version  3.23 
To  a  prompt,  please  type  in  your  questions 

about  the  UNIX  file  system  in  English. 

To  leave,  just  type  ' ‘D'  or  ' (exit) ' . 

Hi. 

How  can  I  help  you? 

#  Bow  can  I  delete  a  file? 


UCEgo:  suggesting  the  plan: 

(PLANFOR55 

(goals55  =  (HELP4  (helpee4  =  *USER*)  (helper4  =  UC) ) ) 

(plan55  =  (SATISFY4 

(need4  =  (KNOW-gaO?  (knower-gaO  =  *USER*) 

(fact-gaO  =  (ACTION12? 

(actore  =  *USER*) ) ) ) ) 

{actor4-0  =  UC) ) ) ) 
based  on  the  situation: 

(UC-HAS-GOAL47  (status47  =  ACTIVE)  (goal47  =  (HELP4  &))) 
(HAS-GOAL-gaO  (planner-gaO  =  *USER*)  (goal-gaO  =  (KNOW-gaO?  &) ) ) 


Here  UCEgo  suggests  a  plan  for  helping  the  user:  satisfy  the  state  of  having  the  user 
know  how  to  delete  a  file.  ACTION  12  represents  “how  to  delete  a  file.’’ 
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UCEgo:  detected  the  goal: 

(UC-HAS-GOAL50  (goalSO  =  (KNOW-gaO?  &) ) ) 
from  the  situation: 

(UC-HAS-INTENTIONIO  (intentionlO  =  <SAT1SFY4  &) ) 

(statuslO  =  ACTIVE) ) 


After  UCEgo  adopts  the  intention  of  carrying  out  the  previous  plan,  UCEgo  adopts  the 
sub-goal  of  having  the  user  know  how  to  delete  a  file.  This  is  a  sub-goal  of  UC  s  goal  of 
helping  the  user. 


UCEgo:  suggesting  the  plan: 

(PLANFOR56 

(goals56  =  (KNOW-gaO?  &) ) 

{plan56  =  (TELL6  (listener6-0  =  *USER*) 

(speaicer6-0  =  UC) 

(propositions  = 

(PLANFOR180 

(goalslSO  =  (DELETE-EFFECTO? 

(DELETE— EFFECT— f rnal— St ate w  — 

(EXISTSO  (exist-ob jectO  =  FILES?) 

(existenceO  =  FALSE) ) ) 
(DELETE-EFFECT-initial-stateO  = 
(EXISTS3  (exist-ob jectS  =  FILES?) 
(existences  =  TRUE) ) ) 
(del-objectO  =  FILES?))) 

(planlSO  =  (UNIX-RM-COMMANDO 

(rm-fileO  =  FILES?) 
(UNIX-RM-COMMAND-effectO  = 
(DELETE-EFFECTO?  &)))))) 

(effects  =  (STATE-CHANGEl  ( f inal-statel  = 

(KNOW-gaO?  &))))))) 

based  on  the  situation: 

(ANSWER-FOR2  (answerS  =  (PLANFOR180  &))  (queryS  =  (ACTION12?  &))) 
(UC-HAS-GOAL50  &) 


After  UC  determines  the  answer,  UCEgo  suggests  the  plan  of  telling  the  user  the  answer 
in  order  the  satisfy  the  goal  of  having  the  user  know  how  to  delete  a  file.  Since  that  is  a 
sub-goal  of  helping  the  user,  it  will  also  help  to  satisfy  that  goal. 
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Use  zm. 

For  exaiqsle,  to  delete  the  file  named  foo,  type 


'rm  foo'  . 


Figure  3.3.  Simple  UC  dialog  showing  sub-goals. 


2.2.  Goals  from  Themes 

When  UC  first  starts  up,  it  has  a  number  of  themes.  These  immediately  give  rise  to 
goals  for  UC.  The  themes  that  have  been  found  to  be  important  for  UC  include  the 
Stay-Alive  and  Ethics  life  themes,  and  the  Consultant  role  theme.  Other  systems  may 
find  that  different  themes  will  be  useful.  Certainly,  systems  that  are  not  consultation  sys¬ 
tems  will  have  a  different  role  theme  than  UC’s  Consultant  role  theme. 

The  Consultant  role  theme  represents  UC’s  job  of  being  a  UNIX  consultant.  It 
motivates  UC  to  behave  as  a  consultant  to  help  the  user.  Therefore,  the  Consultant  role 
theme  leads  UCEgo  to  adopt  the  recurrent  goal  of  helping  the  user.  This  goal  is  a 
recurrent  goal,  since  once  UC  has  helped  the  user,  UC  continues  to  have  the  goal  of  help¬ 
ing  the  user  Unlike  other  goals  that  arise  from  themes,  the  goal  of  helping  the  user  is  not 
a  background  goal.  This  means  that  UCEgo  is  constantly  planning  how  to  satisfy  this 

goal. 

Another  aspect  of  being  a  consultant  involves  being  polite  to  the  client.  So  the  Con¬ 
sultant  role  theme  leads  UCEgo  to  adopt  the  recurrent  background  goal  of  being  polite  to 
the  user  This  goal  is  a  recurrent  goal,  since  UC  never  stops  being  polite  to  the  user.  It  is 
also  a  background  goal,  since  UCEgo  does  not  try  to  plan  how  to  be  polite  to  the  user. 
Instead,  when  a  situation  arises  in  which  UC  should  be  polite,  this  goal  will  become 
activated.  Such  social  situations  include  greetings,  farewells,  and  apologies.  See 
Chapter  IV,  Section  2.4  for  more  details  on  such  social  situations. 

The  Ethics  life  theme  represents  UC’s  desire  to  act  ethically.  It  gives  rise  to  UC  s 
goal  of  ACT-ETHICALLY.  Since  UC  cannot  perform  actions  except  for  comrnunicative 
acts,  UC  only  has  to  worry  about  performing  unethical  communicative  actions.  For 
example  UC  worries  about  providing  information  to  the  user  that  will  help  the  user  per¬ 
form  an  unethical  act.  In  such  situations,  UCEgo  detects  a  conflict  between  UC’s  goal  of 
helping  the  user  (from  the  Consultant  role  theme)  and  UC’s  goal  of  ACT-ETHICALLY. 
Such  goal  interactions  are  described  further  in  Section  3. 

The  Stay-Alive  life  theme  is  an  instance  of  the  Preservation  Theme  (see  [Wilensky, 
19831),  whence  arise  preservation  goals.  This  particular  Preservation  theme  represents 
UC’s  desire  to  preserve  itself.  As  a  result,  it  leads  UC  to  adopt  the  goals  of  preservmg 
the  UC  program  and  preserving  the  UNIX  system  on  which  UC  runs.  Other  preservation 
goals  that  need  to  be  taken  into  account  in  planning  how  the  user  should  do  ^mgs  in 
UNIX  (e.  g.  preserving  the  user’s  files  and  preserving  the  privacy  of  the  user  s  files)  are 
handled  by  UC’s  UNIX  domain  planner  ([Luria,  1985]  and  [Luria,  forthcoming]). 
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Themes  in  UC  and  the  goals  that  they  give  rise  to  are  summanzed 


in  Table  3.1. 


Theme 

goal 

goal-tvpe 

UC-Consultant 
Role  Theme 

UC  help  user 

recurrent  foreground  goal 

UC  be  polite  to  user 

recurrent  background  goal 

UC-Stay-Alive 

Life-Theme 

preserve  UC  program 

recurrent  background  goal 

preverve  UNIX  system 

recurrent  background  goal 

UC-Ethics 

Life-Theme 

UC  act-ethically 

recurrent  background  goal 

Table  3.1.  Themes  that  give  rise  to  goals  in  UC. 


2.3.  Situations  Leading  to  Sub-Goals 


Except  for  those  goals  that  UC  adopts  from  its  themes,  all  of  UC’s  other  goals  are 
sub  seals  or  infrequently,  meta-goals.  This  section  will  show  how  UCEgo  adopts  sub- 
Toalf  and  de'scTibTsome  of  the  sub-goals  found  in  UC.  Other  sub-goals  are  infroduced  as 
appropriate  in  later  sections. 

Sub-goals  are  created  as  part  of  the  planning  process.  M^y  of  UCEgo  s  P^ans  con¬ 
tain  steps  Aat  caU  for  the  achievement  of  a  state.  When  UCEgo  adop^  such  a  plan, 
adopts  L  sub-goal  of  the  achieving  that  state. 

that  adopts  a  sub-goal  whenever  UC  has  the  intennon  of  sansfying  some  state. 


Figure  3.4.  If-detected  daemon  that  adopts  a  sub-goal  from  an  intention. 

An  example  of  a  particular  sub-goal  is  shown  in  Figure  3.5.  The 
shown  allows  UCEgo  to  adopt  the  user’s  goal  of  knowing  something.  This  daemon 
triggered  by  a  class  of  situations  that  consists  of  two  parts. 
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C 


V 


1)  uc  has  the  goal  of  helping  someone. 

2)  That  person  wants  to  know  something. 


When  UCEgo  encounters  a  matching  situation,  it  asserts  that  a  plan  for  helping  Ae 
n.er  iTfo  satisfy  the  sub-goal  of  having  the  user  know  what  the  user  wants  to  know.  This 
Xation  is  a  very  conm,on  oat  for  UC,  because  UC’s  users  usually  want  to  know  some- 

thing  about  UNIX. 


Figure  3.5.  If-detected  daemon  for  detecting  the  sub-goal  of  having  the  user  know. 
Another  example  of  a  sub-goal  situation  is  shown  ^ 
tally.  The  type  of  situation  that  triggers  the  daemon  involves  four  relations. 


1)  UC  has  the  goal  of  acting  ethically. 

2)  Someone,  ?pl,  wants  to  alter  a  file  (alter  includes  delete). 

3)  The  owner  of  the  file  is  someone,  ?p2. 

4)  ?p2  (the  owner)  differs  from  ?pl  (the  alterer). 


After  detecting  such  a  situation,  UCEgo  asserts  that  a  plan  for  acting  ethically  is  to 


V 
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If  UC  had  emotions,  then  it  would  probably  be  frustrated. 


Figure  3.6.  Detect  sub-goal:  prevent  someone  from  altering  someone  else  s  file. 

The  situation  class  encoded  in  this  if-detected  daemon  is  rather  specific,  it  only 
detects  unethical  situations  in  which  someone  wants  to  delete  someone  else  s  files.  A 
more  general  approach  would  be  to  have  an  if-detected  daemon  detect  situations  in 

which: 

1)  Someone  has  an  unethical  goal, 

2)  UC  has  the  goal  of  acting  ethically. 

Then  in  such  situations,  UC  can  adopt  the  sub-goal  of  preventing  that  person  from 
achieving  their  unethical  goal.  With  this  if-detected  daemon,  UCEgo  would  still  need  to 
determine  which  goals  are  unethical.  Such  an  approach  would  help  to  highlight  the 
difference  between  an  agent’s  reaction  to  an  immoral  situation  (attempt  to  prevent  it)  and 
the  agent’s  judgment  of  morality.  Since  it  was  not  the  purpose  of  UCEgo  to  develop  a 
systematic  representation  of  morality,  the  rather  specific  approach  shown  above  was  used 
for  efficiency.  The  same  is  true  of  the  next  if-detected  daemon,  shown  in  Figure  3.7, 
which  encodes  the  related  situation  class  of  someone  wanting  to  know  how  to  alter  some¬ 
one  else’s  file. 
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Figure  3.7.  Detect  sub-goal:  prevent  someone  from  knowing  something  unethical. 

This  if-detected  daemon  encodes  situations  in  which: 

1)  UC  has  the  goal  of  acting  ethically. 

2)  Someone,  ?p  1 ,  wants  to  know: 

3)  a  plan  for  altering  a  file  (altering  includes  the  sub-class  of  deleting). 

4)  The  owner  of  the  file  is  someone,  ?p2. 

5)  ?p2  (the  owner)  differs  from  ?pl  (the  alterer). 

When  UCEgo  detects  such  a  situation,  it  asserts  that  a  plan  for  acting  ethically  is  to 
adopt  the  sub-goal  of  preventing  the  first  person  from  knowing  how  to  alter  the  second 
person’s  file.  Normally  this  type  of  situation  occurs  when  the  user  asks  UC  how  to  alter 
someone  else’s  file.  UC  should  not  help  the  user  to  perform  unethical  actions,  so  in  such 
cases,  UC  should  not  provide  the  user  with  such  information.  However  this  conflicts 
with  UC’s  normal  mode  of  operation  in  which  UC  adopts  the  user’s  goal  of  knowing  in 
order  to  help  the  user.  This  results  in  an  internal  goal  conflict  for  UC.  Section  3 
describes  such  goal  interactions  and  how  they  are  resolved. 


3.  Meta-Goals 

To  correct  user  misconceptions  or  provide  suggestions  to  the  user  does  not  neces¬ 
sarily  require  that  the  system  have  explicit  goals  of  its  own.  Those  types  of  responses 
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can  be  provided  by  simpler  systems  that  do  not  have  goals  and  plans.  However,  a  system 
based  on  planning  for  goals  is  more  flexible,  because  such  a  system  can  much  more 
easily  handle  interactions  among  goals.  Goals  can  interact  either  negatively  by 
conflicting,  or  positively  by  overlapping.  When  UCEgo  detects  a  situation  where  goa^s 
conflict  or  overlap,  it  creates  a  new  goal  for  dealing  with  the  goal  interaction.  Such  goals 
for  dealing  with  other  goals  are  called  meta-goals  ([Wilensky,  1983]). 

Meta-goals  in  UC,  like  UC’s  sub-goals,  are  completely  equivalent  to  all  other  goals 
of  UC  That  is,  meta-goals  are  not  discriminated  from  other  goals  in  UC  either  by 
representational  differences  or  by  differences  in  their  processing.  Of  course,  in  discuss¬ 
ing  goals,  it  is  useful  to  distinguish  meta-goals  and  sub-goals  because  these  types  of  goals 
tend  to  originate  from  different  kinds  of  situations  and  tend  to  have  different  subject 

areas. 

Meta-goals  are  also  useful  for  controlling  the  planning  and  plan  execution  process. 
In  UC,  meta-goals  control  when  UCEgo  tries  to  find  out  information  for  the  user  in  situa¬ 
tions  in  which  UC  does  not  know  the  information.  Also,  when  UCEgo  cannot  find  a 
pre-stored  plan  to  satisfy  one  of  UC’s  goals,  UCEgo  adopts  the  meta-goal  of  knowing  a 
plan  for  finding  out  a  plan  to  satisfy  this  goal.  This  is  an  example  of  meta-planning 
([Wilensky,  1983]),  since  UC  is  planning  to  create  a  plan  that  is  used  to  find  another  plan. 

3.1.  Controlling  Planning 


When  UCEgo  fails  to  find  a  plan  to  satisfy  one  of  UC’s  foreground  goals,  it  adopts 
the  meta-goal  of  knowing  a  plan  for  satisfying  this  goal.  Since  UCEgo  selects  plans  (see 
Chapter  IV  Section  2)  using  if-detected  daemons,  it  does  not  know  whether  it  has  found 
a  plan  for ’a  particular  goal  until  after  any  relevant  if-detected  daemons  have  been 
activated.  So,  after  all  possible  daemons  have  been  given  a  chance  to  activate,  UCEgo 
looks  through  its  memory  to  see  if  there  are  any  foreground  goals  for  which  it  does  not 
have  a  plan  for  satisfying.  For  each  such  unsatisfied  foreground  goal,  UCEgo  adopts  the 
meta-goal  of  knowing  a  plan  for  satisfying  the  unsatisfied  foreground  goal. 

A  very  simple  case  of  such  a  meta-goal  is  found  when  UC  first  starts  up  with  a  new 
user.  At  startup,  UCEgo  adopts  the  Consultant  role  theme  (see  Section  2),  which  leads  to 
the  foreground  goal  of  helping  the  user.  However,  before  the  user  has  stated  a  problem 
to  UC,  UC  does  not  know  exactly  how  it  can  help  the  user.  So  UCEgo  adopts  the  meta¬ 
goal  of  knowing  a  plan  for  helping  the  user.  Then,  since  UC  knows  that  the  Jiser  knows 
how  UC  can  help  the  user,  UCEgo  suggests  the  plan  of  asking  the  user  how  UC  can  he  p 
in  order  to  satisfy  the  meta-goal  of  knowing  a  plan  for  helping  the  user.  Executing  the 
plan  results  in  UC  asking  the  user,  “How  can  I  help  you?’’  A  trace  of  this  processing  is 

shown  in  Figure  3.8. 


Welcome  to  UC  (Unix  Consultant)  version  3.23 
To  a  prompt,  please  type  in  your  questions 

about  the  UNIX  file  system  in  English. 

To  leave,  just  type  ' “D'  or  ' (exit) ' . 


Hi 


UCEgo :  do  not  know  a  single  planfor  the  foreground  goal: 
(UC-HAS-GOAL56  &) 

SO  adding  the  meta-goal: 

(UC-HAS-GOAL57  {goal57  =  (KNOW49?  (knower49  =  UC) 

(fact49  =  ACTlONll?) ) ) ) 

(PLANF0R61?  (goals61  =  (HELPS  &) )  (plan61  =  ACTlONll?)) 


UCEgo  does  not  currently  have  a  specific  plan  for  the  goal  of  helping  the  user,  which  is  a 
foreground  goal,  so  it  adopts  the  meta-goal  of  finding  out  a  plan  for  helping  the  user. 


UCEgo;  suggesting  the  plan: 

(PLANFOR62 

(plan62  =  (ASKS  (asked-forS  =  (QUESTIONS 
(listeners  =  *USER*) 
(speakers  =  UC) ) ) 
(goals62  =  (KNOW49?  &))) 
based  on  the  situation: 


*USER* 

(UC-HAS-GOAL57  &) 


(what-isS 


ACTlONll?) ) ) 


Since  UC  knows  that  the  user  knows  how  UC  can  help,  UCEgo  suggests  the  plan  of  ask¬ 
ing  the  user  in  order  to  find  out  how  to  help  the  user.  This  plan  is  described  in  Chapter 
IV,  Section  2.3. 


The  planner  is  passed: 
(  (HELPS  &) ) 
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The  planner  produces : 
nil 


UCEgo  always  consults  the  UNIX  domain  planner,  whenever  it  wants  to  know  a  plan. 
The  domain  planner  fails  to  devise  a  plan  in  this  case. 

The  generator  is  passed: 

(ASKS  &) 

How  can  I  help  you? 

# 

Figure  3.8.  Trace  showing  meta-goal. 


UCEgo  also  uses  meta-goals  to  control  the  planning  process,  when  UCEgo  does  not 
know  some  information  sought  by  the  user.  In  these  situations,  UCEgo  adopts  the  meta¬ 
goal  of  finding  out  the  information.  Such  situations  are  detected  by  the  if-detected  dae¬ 
mon  shown  in  Figure  3.9.  More  specifically,  UCEgo  adopts  the  meta-goal  (UC-I^S- 
GOAL2)  of  UC  knowing  something  whenever  UC  has  the  goal  (UC-HAS-GOALl)  of 
having  the  user  know  something,  and  UC  does  not  know  (KNOWl)  that. 


Figure  3.9.  Daemon  for  detecting  the  goal  of  finding  out  something  that  UC  does  not  know. 
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Once  UCEgo  has  adopted  the  meta-goal,  the  regular  planning  process  is  used  to 
devise  a  plan  for  UC  to  find  out  the  information.  This  meta-goal  is  meant  to  model  ±t 
behavior  of  human  consultants  who  do  not  know  the  answer  to  a  client’s  question,  but 
can  “look  it  up”  to  find  out  the  answer,  The  meta-goal  can  also  be  thought  of  as  a  sim¬ 
ple  form  of  “curiosity,”  since  UC  wants  to  know  something  when  it  realizes  that  it  does 
not  know  the  information.  Unformnately,  the  current  implementation  of  UC  does  not 
have  the  capability  to  “look  up”  answers.  However,  the  plan  that  UC  discovers  for 
looking  up  answers  may  be  useful  to  the  user,  since  the  user  does  have  the  capability  to 
“look  up”  answers.  In  such  cases,  when  UCEgo  comes  up  with  a  plan  for  finding  out 
the  answer  to  the  user’s  query,  and  KNOME  does  not  believe  that  the  user  already  toows 
this  plan,  then  UCEgo  suggests  this  plan  to  the  user.  Section  5.3  discusses  how  UCEgo 
makes  suggestions  in  greater  detail,  while  Section  5.5  shows  a  trace  of  UCEgo  adopting 

this  type  of  meta-goal. 

3.2.  Mutual  Inclusion 

Meta-goals  are  used  to  deal  with  both  positive  and  negative  interactions  between 
goals.  One  way  in  which  goals  can  interact  positively  is  through  mutual  inclusion 
([Wilensky,  1983]).  This  describes  situations  in  which  a  planner  has  the  same  or  similar 
goals  for  different  reasons.  In  such  situations,  the  planner  can  merge  the  goals  into  a  sin¬ 
gle  goal.  This  saves  resources,  because  the  planner  no  longer  has  to  plan  several  times 

nor  execute  many  similar  plans. 

When  UCEgo  finds  that  it  has  two  goals  that  are  similar,  it  adopts  the  meta-goal  of 
merging  the  redundant  goals.  The  redundant  goals  may  actually  be  identical,  or  they 
may  be  just  similar  enough  to  be  merged  successfully  into  a  single  goal.  For  example, 
consider  what  happens  when  the  user  asked  UC,  “Is  cp  used  to  copy  files? 

In  processing  this  query,  UC’s  goal  analysis  component,  PAGAN,  deduces  that  the 
user’s  goal  is  to  know  whether  Cp  is  a  plan  for  copying  files.  PAGAN  also  deduces  that 
this  goal  has  two  possible  parent  goals  (one  or  both  of  which  might  hold). 

1)  The  user  wants  to  know  the  effects  of  the  Cp  command. 

2)  The  user  wants  to  know  how  to  copy  files. 

To  see  why  this  added  level  of  goal  analysis  is  necessary,  consider  the  slightly  dif¬ 
ferent  query,  “Is  cp  used  to  create  files?”  The  answer  to  this  query  is,  “No.’’  However 
this  is  not  a  very  good  answer.  In  fact,  any  human  consultant  who  only  replied.  No  in 
this  case  would  be  labeled  uncooperative.  The  reason  why  “No”  is  not  a  good  answer 
for  this  query,  whereas  “Yes”  is  a  reasonable  answer  for  the  first  query  is  because  the 
“No”  answer  only  superficially  addresses  the  user’s  goals.  It  only  addresses  *e  user  s 
immediate  goal,  to  know  whether  or  not  Cp  is  used  to  create  files,  but  does  not  adless 
either  of  the  two  possible  goals  that  motivate  that  goal:  the  user  wants  to  know  the  ettects 
of  the  cp  command,  or  the  user  wants  to  know  how  to  create  files,  or  both.  To  provide  a 
more  cooperative  answer  in  such  situations,  UCEgo  volunteers  additional  information  by 
addressing  the  user’s  higher  level  goals  as  well  as  the  user’s  immediate  goal. 
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Volunteering  information  in  such  cases  is  described  in  Section  5.4. 

The  second  query  shows  that  UCEgo  sometimes  needs  to  address  all  of  the  user’s 
goals  rather  than  just  the  user’s  immediate  goal.  However,  if  UCEgo  were  to  address  all 
of  the  user’s  goals  in  the  first  query,  then  it  would  end  up  provi^ng  three  very  similar, 
indeed  redundant,  answers  to  the  user.  UCEgo  might  approach  this  problem  of  redundant 
answers  in  one  of  two  ways.  It  could  always  handle  only  the  user’s  immediate  goal  and 
then  volunteer  more  information  only  if  it  discovers  that  satisfying  the  user  s  immediate 
goal  does  not  contribute  to  satisfying  the  higher  level  goals  that  motivate  the  immediate 
goal.  The  problem  with  this  approach  is  that  it  is  fairly  difficult  to  tell  whether  or  not 
satisfying  the  immediate  goal  helps  to  satisfy  the  underlying  goals.  In  fact,  a  planner  will 
usually  have  to  plan  to  satisfy  the  underlying  goals  before  it  can  make  such  a  judgment. 

Since  a  planner  often  must  plan  for  the  underlying  goals  anyway,  UCEgo  uses  the 
strategy  of  always  planning  to  satisfy  all  of  the  user’s  goals  and  then  noticing  when  these 
goals  overlap  to  prevent  redundant  answers.  Figure  3.10  shows  the  if-detected  daemon 
that  notices  situations  with  potential  goal  overlap.  Whenever  UC  has  two  different  goals 
(UC-HAS-GOALl  and  UC-HAS-GOAL2)  of  wanting  the  user  (PERSONl)  to  know 
something,  and  the  answer  (ANSWER-FORl  and  ANSWER-FOR2)  for  those  queries  are 
similar  (implemented  by  the  procedural  test,  UC-test-similar),  then  UCEgo  adopts  the 
meta-goal  (UC-HAS-GOAL3)  of  merging  the  redundant  goals  (MERGE- 
REDUNDANT-GOALS). 


Figure  3.10.  If-detected  daemon  for  detecting  overlapping  goals. 

The  procedural  test,  UC-test-similar,  checks  to  see  if  the  two  goals  are  similar 
enough  to  be  merged.  It  first  matches  the  two  answers  to  see  if  they  are  the  same.  If  so, 
then  the  two  goals  can  be  merged.  It  also  has  knowledge  that  certain  types  of  relations 
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are  similar  enough  that  they  convey  essentially  the  same  information.  For  example, 
HAS-EFFECT  and  PLANFOR  are  similar  enough  to  be  merged,  provided  of  course  that 

they  relate  similar  concepts. 

The  trace  of  a  UC  session  shown  in  Figure  3.11,  shows  how  UCEgo  merges  goals 
during  the  processing  of  the  user  query,  “Is  cp  used  to  copy  files?”  By  adopting  a 
three  potential  user  goals,  UCEgo  detects  the  three  goals: 

1)  UC  wants  the  user  to  know  whether  cp  is  used  to  copy  files  (UC-HAS- 
GOAL67) 

2)  UC  wants  the  user  to  know  the  effects  of  the  Cp  command  (UC-HAS- 
GOAL66) 

3)  UC  wants  the  user  to  know  a  plan  for  copying  files  (UC-HAS-GOAL68) 


UCEgo  cannot  tell  that  these  goals  are  similar  until  after  it  has  deduced 
of  the  descriptions  in  UC’s  goals.  For  instance,  the  referent  (encoded  as  an  ANSWER- 
FOR  relation)  for  the  goal  of  knowing  the  effects  of  the  cp  command  is  the  HAS- 
EFFECT21  relation,  whereas  the  referent  of  the  goal  of  knowing  a  plan  for  copying  files 
i<;  the  PLANFOR340  relation.  These  are  similar,  albeit  different  relations,  so  they  are 
merging.  Since  .hey  both  relate  a  UNIX-CP-COMMAND  to  a  COPY- 
FILE -EFFECT,  UC- test- similar  decides  that  they  can  indeed  be  merged.  Another  type  o 
similarity  is  found  when  one  answer  is  contained  in  the  other.  In  Ms  exampl^  the 
answer  for  *e  goal  of  knowing  whether  cp  is  a  plan  for  copying  files  ts  the  HAS- 
TRUTH-VALUEO  relation  relating  the  truth-value ,  TRUE,  and  the  proposition,  PLAN¬ 
FOR?  1  that  the  cp  command  is  a  plan  for  copying  files.  When  comparing  this  answer, 
only  the  propositional  content  is  compared.  Eventually,  all  three  goals  are  merged  by 
discarding  all  but  the  immediate  goal  (the  merging  of  goals  is  desenbed  in  more  detail  in 

Chapter  IV,  Section  2.5). 

The  final  answer  is  shortened  to  just,  “Yes,”  rather  than  “Yes,  cp  is  used  to  copy 
files  ”  This  is  done  since  the  proposition,  “cp  is  a  plan  for  copying  files,  is  already  part 
of  the  context  (it  is  part  of  the  user’s  query).  This  is  an  example  of  pruning  the  concepts 
to  be  expressed  to  the  user  and  is  described  in  Chapter  V,  Section  2. 


- - - - - - - - 

Welcoine  to  UC  (Unix  Consultant)  version  3.23 
To  a  prompt,  please  type  in  your  questions 

about  the  UNIX  file  system  in  English. 

To  leave,  just  type  ' 'D'  or  ' (exit) 

C 

Hi. 

How  can  I  help  you? 

#  Is  cp  used  to  copy  files? 

L 


The  parser  produces: 
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(ASKIO  (asked-forlO  = 

(QUESTIONIO 
(what-islO  = 

(PLANFOR71?  (goals71  =  (COPY-FILE-EFFECTO? 

(copy-to-f ileO  =  FILES?) 
(copy-f rom-f ileO  =  FILE4?))) 
(plan71  =  UNIX-CP-COMMANDO) ) ) ) ) 
(listenerlO  =  UC) 

(speakerlO  =  *USER*) ) 

(COPY-FILE-ACTIONO? 

(COPY-FILE-ACTION-ef fectO  =  (COPY-FILE-EFFECTO?  &))) 


The  goal  analyzer  produces: 

( (KAS-GOAL-ga2 

(planner-gaO  =  *USER*) 

(goal-ga2  =  {KNOW-ga2?  (knower-gaO  =  *USER*) 

(fact-ga2  =  SOMETH ING-gaO?) )) ) 


(HAS-GOAL-gal 

(goal-gal  =  (KNOW-gal?  (knower-gal 

(fact-gal  = 

(planner-gal  =  *USER*) ) 
(HAS-GOAL-gaO 
(planner-ga2  =  *USER*) 

(goal-gaO  =  (KNOW-gaO?  (knower-ga2 

(fact-gaO  = 


=  *USER*) 
(PLANFOR71?  &)))) 


=  *USER*) 
ACTION-gaO?) ) ) > ) 


PAGAN  deduces  that  the  user  has  the  goals: 

know  whether  cp  is  a  plan  for  copying  files  —  HAS-GOAL-gal 

know  a  plan  (ACTION-gaO)  for  copying  files  —  HAS-GOAL-gaO 

know  the  effects  (SOMETHING-gaO)  of  the  cp  command  —  HAS-GOAL-ga2 


UCEgo :  suggesting  the  plan: 

(PLANFOR72  (goals72  =  (HELPS  (helpeeS  =  *USER*)  (helpers  =  UC) ) ) 
(plan72  =  (SATISFY6  (need6  =  (KNOW-ga2?  &) ) 

(actor6  =  UC) ) ) ) 

based  on  the  situation: 

(UC-HAS-GOAL63  (status63  =  ACTIVE)  (goal63  =  (HELPS  &) ) ) 
(HAS-GOAL-ga2  &) 

UCEgo:  suggesting  the  plan: 

(PLANFOR73  (goals73  =  (HELPS  &)) 

(plan73  =  (SATISFY?  (need?  =  (KNOW-gal?  &) ) 

(actor?  =  UC) ) ) ) 

based  on  the  situation: 

(UC -HAS -GOAL 6 3  &) 
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(HAS-GOAL-gal  &) 

UCEgo:  suggesting  the  plan: 

(PLANFOR74  (goals74  =  (HELPS  &) ) 

(plan74  =  (SATISFY8  (needS  =  (KNOW-gaO?  &) ) 

(actorS  =  UC) ) ) ) 

based  on  the  situation: 

(UC-HAS-GOAL63  &) 

(HAS-GOAL-gaO  &) 

UCEgo:  detected  the  goal: 

(UC-HAS-GOAL66  (goal66  =  <KNOW-ga2?  &) ) ) 
from  the  situation: 

(UC-HAS-INTENTIONll  (intentionll  =  {SATISFY6  &) ) 

(statusll  =  ACTIVE)) 

UCEgo:  detected  the  goal: 

(UC-HAS-GOAL67  (goal67  =  (KNOW-gal?  &) ) ) 
from  the  situation: 

(UC-HAS-INTENTIONIO  (intentionlO  =  (SATISFY7  &)) 

(statuslO  =  ACTIVE) ) 

UCEgo:  detected  the  goal: 

(UC-HAS-GOAL68  (goal68  =  (KNOW-gaO?  &) ) ) 
from  the  situation: 

(UC-HAS-INTENTION9  (intention9  =  (SATISFY8  &) ) 

(status9  =  ACTIVE) ) 


UCEgo  adopts  all  three  of  the  user’s  goals  as  its  own. 


UCEgo:  trying  to  find  effects  for  UNIX-CP  COMMANDO 
the  effects  are: 

( (HAS-EFFECT21  (command-of-ef fect21  =  (UNIX-CP-COMMANDO  &) ) 

(ef fect-of-command21  = 

(COPY-FILE-EFFECT-0  (copy-to-f ile-0  =  FILE-2) 

(copy-f rora-f ile-0  =  FILE-3) )))) 


This  is  to  help  satisfy  the  sub-goal  of  having  the  user  know  the  effects  of  the  cp  com¬ 
mand. 


UCEgo:  checking  the  truth  value  of  the  proposition. 
(PLANFOR71?  &) 
the  proposition  is  TRUE 
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This  is  to  help  satisfy  the  sub-goal  of  having  the  user  know  whether  cp  is  used  to  copy 
files. 


UCEgo:  suggesting  the  plan: 

(PLANFOR75 

(goals75  =  (KNOW-gal?  &) ) 

(plan75  = 

(TELLS  (effects  =  (STATE-CHANGEl 

(f inal-statel  =  (KNOW-gal?  &) ) ) ) 

(listenerS-0  =  *USER*) 

(speakerS-0  =  UC) 

(propositions  = 

(HAS-TRUTH-VALUEO  (truth-valueO  =  TRUE) 

(t-v-propO  =  (PLANFOR71?  &))))))) 

based  on  the  situation: 

(ANSWER-FORS  (answerS  =  (HAS-TRUTH-VALUEO  &)) 

(queryS  =  (PLANFOR71?  i) )  ) 

(UC-HAS-GOAL67  &) 

UCEgo:  suggesting  the  plan: 

(PLANFOR7  6 

(goals76  =  (KNOW-ga2?  &)  ) 

(plan76  = 

(TELL6  (effect6  =  (STATE-CHANGE2 

(final-state2  =  (KNOW-ga2?  &)))) 

(listener6-0  =  *USER*) 

(speaker6-0  =  UC) 

(proposition6  = 

(HAS-EFFECT21  (command-of-ef fect21  = 

(UN IX -CP -COMMANDO  &)) 

(ef  fect-of-coniinand21  = 
(COPY-FILE-EFFECT-0 
(copy-to-f ile-0  =  FILE-2) 

(copy-f rom-f ile-0  =  FILE-3) ))))))) 

based  on  the  situation: 

(ANSWER-FOR4  (answer4  =  (HAS-EFFECT21  &) ) 

(query4  =  SOMETHING-gaO?) ) 

(UC-HAS-GOAL66  &) 

UCEgo:  detected  the  goal: 

(UC-HAS-GOAL6 9  (goal69  =  (MERGE-REDUNDANT-GOALS2 

(merge-goal-A2  =  (UC-HAS-GOAL66  &) ) 
(merge— goal— B2  =  (UC— HAS— GOAL67  &))))) 

from  the  situation: 

(UC-HAS-GOAL67  &) 

(UC-HAS-GOAL66  &) 

(ANSWER-FORS  &) 

(ANSWER-FOR4  &) 
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UCEgo  detects  a  situation  with  redundant  goals,  so  it  adopts  the  meta-goal  (UC-HAS- 
GOAL69)  of  merging  the  redundant  goals. 


UCEgo:  suggesting  the  plan: 

(PLANF0R79 

{goals79  =  (MERGE-REDUNDANT-GOALS2  &)) 

(plan79  =  (UC-merge-goalsl  (merge-Al  =  (UC -HAS -GOAL 6 6  &) ) 

(nierge— B1  =  (UC-HAS— GOAL67  &))))) 

based  on  the  situation: 

(UC-HAS -G0AL6 9  &) 

UCEgo:  merging  the  overlapping  goals: 

(UC-HAS-GOAL66  &) 

(UC-HAS-GOAL67  &) 

by  discarding  the  goal,  UC-HAS-G0AL66 
and  its  sub-goal,  UC-HAS-INTENTION12 


UCEgo  merges  the  goals  by  discarding  one  of  the  goals. 


The  planner  is  passed: 

{ (COPY-FILE-EFFECTO?  &)) 


This  is  to  help  satisfy  the  sub-goal  of  having  the  user  know  a  plan  for  copying  files. 


The  planner  produces: 

(PLANFOR340 

(goals340  =  (COPY-FILE-EFFECTO?  &)> 

(plan340  =  (UNIX-CP-COMMANDl  (cp-dest-f ilel  =  FILES?) 

(cp-source-f ilel  =  FILE4?) 
(UNIX-CP-COMMAND-ef fectl  = 
(COPY-FILE-EFFECTO?  &))))) 
(HAS-FILE-NAME17  (named-f ilel7  =  FILES?) 

(file-namel7  =  (lisp=  nil))) 
(HAS-FILE-NAME18  (named-f ilel8  =  FILE4?) 

(file-namel8  =  (lisp=  nil))) 

(CP-HAS-FORMATO 

(CP-HAS-FORMAT-CommandO  =  (UNIX-CP-COMMANDl  &)) 
(CP-HAS-FORMAT-formatO  = 

(CP-FORMATO  (CP-FORMAT-two-f ile-argO  = 

(CP-TWO-FILE-SEQO  (cp-dest-f ile-argO  = 

(file-namel7  = 
aspectual-of 
(HAS-FILE-NAME17  &))) 
(cp-source-f ile-argO  = 
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(f ile-namel6  = 
aspectual-of 
(HAS-FILE-NAME18  &))))) 
(CP-FORMAT-stepO  =  cp) ) ) ) 

{ HAS  -COMMAND  -NAME  9  0 

(HAS-COMMAND-NAME-named-obj90  =  (UNIX-CP -COMMAND 1  &)) 

(HAS -COMMAND -NAME -name 90  =  cp) ) 

UCEgo;  suggesting  the  plan; 

(PLANFOR80 

(goals80  =  (KNOW-gaO?  &) ) 

(plan80  =  (TELL?  {effect7  =  (STATE-CHANGE3 

(final-state3  =  (KNOW-gaO?  &)))) 
(listener7-0  =  *USER*) 

(speak.er7-0  =  UC) 

(proposition7  =  (PLANFOR340  &))))) 
based  on  the  situation: 

{ANSWER-FOR6  (answer6  =  (PLANFOR340  &) )  (query6  =  ACTION-gaO . ) ) 
(UC-HAS-GOAL68  &) 

UCEgo:  detected  the  goal: 

(UC-HAS-GOAL7 0  (goal70  =  (MERGE -REDUNDANT -GOAL S3 

(merge-goai-A3  =  (UC -HAS -GOAL 67  &) ) 
(merge-goal-B3  =  (UC-HAS-GOAL68  &))))) 

from  the  situation: 

(UC-HAS-GOAL68  &) 

(UC-HAS-GOAL67  &) 

(ANSWER-FOR6  4) 

(ANSWER-FOR5  &) 


UCEgo  detects  another  pair  of  overlapping  goals. 


UCEgo;  suggesting  the  plan: 

(PLANFOR81 

(goals81  =  (MERGE-REDUNDANT-GOALS3  &)) 

(plan81  =  (UC-merge-goals2  (merge-A2  =  (UC-HAS-GOAL67  &) ) 

(merge-B2  =  (UC-HAS-GOAL68  &))>)) 

based  on  the  situation: 

(UC-HAS-GOAL70  &) 

UCEgo:  merging  the  overlapping  goals; 

(UC-HAS-GOAL67  &) 

(UC-HAS-GOAL68  &) 

by  discarding  the  goal,  UC-HAS-GOAL68 
and  its  sub-goal,  UC-HAS-INTENTION15 

Express:  not  expressing  PLANFOR71?, 

since  it  is  already  in  the  context. 
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The  generator  is  passed: 
(TELLS  &) 

Yes. 


Figure  3.1 1.  UC  dialog  showing  the  meta-goal  of  merging  redundant  goals. 


3.3.  Goal  Conflict 

Goals  can  interact  negatively  by  conflicting.  When  UCEgo  detects  a  situation  in 
which  UC  has  two  goals  that  conflict  with  one  another,  UCEgo  adopts  the  meta-goal  of 
resolving  the  goal  conflict.  A  frequent  type  of  goal  conflict  situation  is  found  when  a 
planner  both  wants  to  achieve  some  state  and  wants  to  prevent  that  state  from  occurring. 
UCEgo  detects  such  situations  with  the  if-detected  daemon  shown  in  Figure  3.12. 


Figure  3.12.  If-detected  daemon  for  detecting  goal  conflict. 

An  example  of  a  goal  conflict  situation  is  when  the  user  asks  UC,  “How  can  I 
delete  UC?”  In  this  case,  the  usual  flow  of  processing  leads  UCEgo  to  adopt  the  user  s 
goal  of  having  the  user  know  a  plan  for  deleting  the  UC  program.  This  sub-goal  can  be 
traced  back  to  UC’s  goal  of  helping  the  user,  which  in  turn  arose  from  UC  s  Consultant 

role  theme  (see  Section  2). 

In  parallel  to  this,  UCEgo  also  has  a  Stay-Alive  life  theme,  which  gives3  rise  to 
UC’s  goal  of  preserving  the  UC  program.  This  is  a  background  goal  (see  Section  1 
Types  of  Goals),  which  means  that  UCEgo  does  not  immediately  plan  to  satisfy  the  goal. 
Rather  the  goal  becomes  active  only  after  UCEgo  detects  a  relevant  situation,  such  as  in 
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the  present  example.  Whenever  someone  wants  to  know  how  to  alter  something  that  UC 
wishes  to  preserve,  UCEgo  adopts  the  sub-goal  of  preventing  the  user  from  knowing  how 
to  do  that.  In  this  example,  the  user  wants  to  delete  (a  specific  kind  of  altering)  the  UC 
program,  which  UC  wants  to  preserve.  So,  UCEgo  adopts  the  sub-goal  of  preventing  the 
user  from  knowing  how  to  delete  the  UC  program.  The  if -detected  daemon  that  detects 
such  simations  is  shown  in  Figure  3.13. 


Figure  3.13.  Daemon  that  detects  the  sub-goal  of  preventing  someone  from  knowing. 

At  this  point,  these  two  lines  of  processing  interact  with  a  goal  conflict.  On  the  one 
hand,  UC  wants  to  help  the  user  and  hence  wants  the  user  to  know  how  to  delete  the  UC 
program.  On  the  other  hand,  UC  wants  to  preserve  the  UC  program  and  hence  wants  to 
prevent  the  user  from  knowing  how  to  delete  the  UC  program.  The  goals  of  wanting  the 
user  to  know  and  wanting  to  prevent  the  user  from  knowing  serve  to  activate  the 
conflict-detection  daemon  shown  earlier  in  Figure  3.12.  Activating  the  daemon  gives  UC 
the  goal  of  resolving  the  conflict.  In  this  case,  the  meta-plan  of  abandoning  the  lower 
priority  goal  (helping  the  user)  is  used  to  resolve  the  conflict.  Thus,  UC  does  not  help  the 
user  by  telling  the  user  how  to  delete  UC.  Conflict  resolution  is  described  in  Chapter  IV, 
Section  2.5. 


4.  Handling  User  Misconceptions 

User  misconceptions  are  commonly  encountered  in  systems  like  consultant  pro¬ 
grams  where  the  system  knows  more  than  the  user.  A  user  is  said  to  have  a  misconcep¬ 
tion  when  the  user’s  beliefs  conflict  with  what  the  consultation  system  knows.  In  order 
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to  respond  properly  in  such  cases,  the  consultant  system  must  first  determine  that  the 
user’s  beliefs  conflict  with  what  the  system  believes,  and  then  correct  the  user  s  miscon¬ 
ception. 

4.1.  Other  Approaches  to  User  Misconceptions 

Other  systems  that  have  dealt  with  user  misconceptions  use  one  of  two  common 
approaches.  The  first  approach  compiles  an  a  priori  list  of  possible  user  misconceptions 
for  use  in  detecting  misconceptions.  This  is  common  among  ITS  (Intelligent  Tutoring 
Systems)  (e.  g.  [Brown  and  Burton,  1978],  [Stevens  et  al.,  1979],  [Sleeman  and  Smith, 
1981],  [Johnson  and  Soloway,  1984],  [Anderson  et  al.,  1985],  and  [Reiser  et  al.,  1985]). 
These  systems  are  not  very  flexible,  since  they  cannot  deal  with  any  user  misconceptions 
that  are  not  listed  among  their  precompiled  a  priori  lists. 

Another  approach  attempts  to  detect  classes  of  misconceptions.  Among  the  best  of 
these  is  Kaplan’s  CO-OP  natural  language  database-query  system  ([Kaplan,  1983]), 
which  handles  a  class  of  faulty  user  presumptions.  An  example  from  CO-OP  is  shown  in 

Figure  3.14. 


User:  Who  advises  projects  in  area  36? 

CO-OP:  I  don’t  know  of  any  area  #36. 

Figure  3.14.  CO-OP  example  with  hedged  response  to  misconception. 


The  user  in  the  CO-OP  example  believes  that  there  is  an  area  36.  In  processing  the 
user’s  query,  CO-OP  finds  that  there  is  no  area  36  listed  in  its  database,  so  it  detects  a 
possible  user  misconception:  the  user  may  mistakenly  presume  that  there  is  an  area  36 
when  in  actuality  there  might  not  be  an  area  36.  Note  that  CO-OP’ s  reply  does  not  actu¬ 
ally  correct  the  user’s  misconception,  rather  it  hedges ,  claiming  that  it  does  not  know  of 
any  area  #36.  By  hedging,  CO-OP  cannot  correct  the  user’s  misconception,  but  can  only 
suggest  to  the  user  that  the  user  might  be  mistaken.  CO-OP  is  unable  to  take  corrective 
action,  because  it  does  not  assume  either  an  open  or  closed  world  m^el  for  its  database. 
As  a  result,  it  cannot  tell  from  the  fact  that  there  is  no  area  36  in  its  database  whether 
there  really  is  no  area  36,  or  if  area  36  was  just  left  out  of  its  database.  Unlike  UC,  in 
which  the  KNOME  subcomponent  models  UC’s  own  knowledge  with  meta-knowledge 
(see  Chapter  II,  Section  4),  CO-OP  does  not  have  a  model  of  its  own  database. 

A  corrective  response  is  shown  in  Kaplan’s  example  of  a  cooperative  human,  shown 
in  Figure  3.15. 
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User;  Which  students  got  a  grade  of  F  in  CS105  in  Spring  1980? 
Human;  CS105  was  not  given  in  Spring  1980. 


Figure  3.15.  Kaplan’s  example  of  a  cooperative  human  respondent. 


Because  CO-OP  does  not  adopt  either  an  open  or  closed  world  model,  it  would  not 
be  able  to  deny  that  CS105  was  given  in  Spring  1980  as  in  Kaplan’s  example  of  a 
cooperative  human.  CO-OP  would  only  be  able  to  suggest  a  misconception  by  saying 
something  like,  “I  don’t  know  of  any  CS105  in  Spring  1980.”  To  be  able  to  actually 
correct  the  user,  CO-OP  would  need  to  know  that  the  absence  of  a  CS105  among  the 
Spring  1980  courses  implies  that  there  was  no  CS105  offered  then.  That  is,  CO-OP 
would  need  meta-knowledge.  Since  CO-OP  was  designed  to  be  easily  transportable 
among  different  databases,  it  did  not  have  such  non-transportable  meta-knowledge. 

The  DAIQUIRY  module  of  HAM-ANS  ([Marburger,  1986])  extended  the  miscon¬ 
ception  approach  of  CO-OP  to  include  conceptual  failures  in  which  the  user  asks  about 
objects  not  modeled  by  the  database.  Because  DAIQUIRY,  like  CO-OP,  did  not  have 
meta-knowledge,  it  too  could  only  hedge  its  replies  to  the  user.  For  example,  it  would 
reply,  “The  system  has  no  knowl^ge  about  ‘SHIP’,”  when  SHIP  was  not  in  its  concep¬ 
tual  hierarchy. 

[Mays,  1980]  and  [Webber  and  Mays,  1983]  report  efforts  to  deal  with  user  miscon¬ 
ceptions  that  can  be  found  by  constraint  violations  on  relations.  For  example,  if  the 
TEACH  relation  is  constrained  to  relate  only  FACULTY  to  COURSES,  then  the  system 
can  detect  a  misconception  if  the  user  asks  about  UNDERGRADUATES  that  TEACH. 
This  type  of  relational  constraint  can  be  considered  a  kind  of  implicit  meta-knowledge. 
It  differs  from  the  explicit  meta-knowledge  of  KNOME  in  that  relational  constraints  can 
only  be  used  to  detect  misconceptions  about  what  can  be  the  case,  and  not  misconcep¬ 
tions  about  what  is  the  case.  For  example,  relational  constraints  can  be  used  to  deduce 
that  only  commands  can  have  command-options,  but  not  whether  any  particular  com¬ 
mand  has  any  particular  command-option. 

After  a  user  misconception  has  been  detected,  it  must  be  corrected.  [McCoy,  1985] 
and  [McCoy,  1987]  discuss  strategies  for  correcting  object-oriented  misconceptions. 
[Quilici  et  al.,  1987]  discusses  correcting  plan-oriented  misconceptions  in  AQUA. 
AQUA  assumes  a  closed  world  model  for  its  knowledge  base  of  plans,  called  an  ‘advi¬ 
sor  model.”  As  a  result  of  this  assumption,  AQUA  can  only  model  perfect  advisors  that 
have  complete  knowledge  of  the  domain.  If  AQUA’s  advisor  model  were  incomplete, 
then  AQUA  would  tend  to  mislead  the  user.  For  example,  if  an  obscure  side  effect  of  a 
plan  were  inadvertently  left  out  of  AQUA’s  knowledge  base,  then  AQUA  would  mislead 
the  user  to  believe  that  the  plan  did  not  have  this  a  side-effect.  Some  form  of  meta¬ 
knowledge  would  be  required  to  allow  AQUA  to  model  an  advisor  without  perfect 
knowledge  of  the  domain. 


4.2.  Detecting  Misconceptions  in  UC 


User  misconceptions  are  detected  by  UC  during  the  processing  of  the  user  s  query. 
Currently,  UC  only  handles  relational  misconceptions,  that  is,  misconceptions  in  which 
the  user  believes  a  relation  holds  between  two  objects  when  in  fact,  such  a  relation  can¬ 
not  hold  or  does  not  happen  to  hold  between  those  particular  objects.  UC  does  not  han¬ 
dle  object-oriented  misconceptions,  such  as  those  for  which  [McCoy,  1985]  discusses 
correction  strategies. 

In  processing  the  user’s  query,  UC  checks  to  see  whether  all  relations  mentioned  by 
the  user  in  the  user’s  query  have  a  counterpart  in  UC’s  knowledge  base.  For  example,  if 
the  user  asks,  “What  does  Is  -e  do?’’,  then  UC’s  parser/understander  understands  part  of 
this  as  a  HAS -OPTION  relation  relating  an  instances  of  the  Is  command  and  an  instance 
of  the  -e  option.  While  looking  for  the  effects  of  the  command,  UC  finds  that  there  is  no 
corresponding  HAS-OPTION  relation  between  the  Is  command  and  the  -e  option  in 
UC’s  knowledge  base.  At  this  point,  UC  suspects  that  the  user  may  have  a  misconcep¬ 
tion. 

In  order  to  see  whether  the  user  actually  has  a  misconception,  or  whether  UC  just 
lacks  information  about  this  particular  option  of  this  command,  UC  checks  with  Ae 
KNOME  subcomponent,  which  models  the  limitations  of  UC’s  knowledge  base  using 
meta-knowledge  (see  Chapter  II,  Section  4).  If  KNOME  has  meta-knowledge  that  UC 
knows  all  of  the  options  of  this  command,  then  UC  knows  that  the  user  has  a  misconcep¬ 
tion.  On  the  other  hand,  if  the  options  of  this  command  are  not  covered  by  KNOME’s 
meta-knowledge,  then  UC  cannot  assume  that  the  user  has  a  misconception.  Instead,  UC 
must  assume  that  it  lacks  information  about  this  command/option  combination. 

4.3.  Correcting  Misconceptions 


After  UC  has  determined  either  that  the  user  has  a  misconception  or  that  UC  lacks 
knowledge,  UCEgo  decides  how  UC  should  reply  to  the  user.  When  the  user  has  a 
misconception,  UCEgo  tries  to  correct  this  misconception  by  denying  that  what  the  user 
mistakenly  believes  is  the  case.  On  the  other  hand,  if  UC  determines  that  it  lacks  infor¬ 
mation,  then  UCEgo  apologizes  to  the  user  for  not  knowing  the  answer  to  the  user’s 
query.  These  two  types  of  responses  are  shown  in  the  UC  session  of  Figure  3.16. 
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Welcome  to  UC  (Unix  Consultant)  version  3.23 
To  a  pronfJt,  please  type  in  your  questions 

about  the  UNIX  file  system  in  English. 

To  leave,  just  type  ' *D'  or  ' (exit) ' . 

Hi. 

How  can  I  help  you? 

#  What  does  who  -b  do? 

who  does  not  have  a  -b  option. 

#  What  does  ruptime  -t  do? 

I'm  sorry,  I  do  not  know  that. 


Fiffiire  1 6.  UC  session  showing  different  UC  responses  to  possible  misconceptions. 

“  “O'”'"  ”■ 


In  the  first  query,  UC  corrects  the  user’s  misconception  that  who  has  a  -b  option.  It 
does  this  by  first  noticing  that  the  user’s  usage  of  “who  -b’’  translates  into  a  HAS- 
OPTION  relation  between  a  UNIX-WHO-COMMAND  and  a  -b-OPTION.  There  is  no 
equivalent  HAS-OPTION  relation  in  UC’s  knowledge  base,  so  UC  suspects  a  possible 
user  misconception.  To  see  if  this  is  the  case  or  if  UC  just  lacks  knowledge  about  this 
particular  option,  UC  consults  the  meta-knowledge  stored  in  KNOME.  The  appropnate 
meta-knowledge  in  this  case  is  the  fact  that  UC  knows  all  the  options  of  all  simple  com¬ 
mands.  Since  who  is  a  simple  command,  and  since  the  -b-OPTION  is  not  listed  among 
the  options  of  UNIX-WHO-COMMAND  in  UC’s  knowledge  base,  KNOME  can  infer 
that  there  is  no  such  option  for  who.  Next,  UCEgo  decides  that  UC  should  correct  the 
user’s  misconception  by  denying  the  existence  of  a  -b  option  for  who. 

On  the  other  hand,  in  the  second  query,  UC  professes  ignorance  about  the  -t  option 
of  the  ruptime  command.  As  in  the  previous  query  about  who,  UC  detects  a  possible 
misconception  when  it  does  not  find  a  -t  option  listed  for  ruptime  in  its  knowledge  base. 
However,  in  this  case,  ruptime  is  a  complex  command,  so  the  previous  meta-knowledge 
does  not  apply  There  is  no  meta- knowledge  about  the  options  of  complex  commands 
(due  to  not  enough  programming  by  UC’s  implementors  rather  than  any  inherent  nota¬ 
tion  of  UC),  so  UC  cannot  tell  if  ruptime  has  a  -t  option.  In  order  to  be  polite,  UCEgo 
apologizes  to  the  user  for  not  knowing. 


4.4.  An  Example  Trace 


The  user  of  Figure  3.17  has  the  misconception  that  Is  has  a  -v  option.  Since  Is 
ignores  unknown  options,  Is  -v  would  do  the  same  thing  as  Is.  So,  a  system  that  did  not 
detect  and  correct  user  misconceptions  and  just  told  the  user  that  Is  -v  does  the  same 
thing  as  Is  would  be  technically  correct,  although  misleading.  Yet,  a  corrective  answer 
such  as  UC  gives,  which  technically  does  not  answer  the  user’s  question,  is  a  much  better 

answer. 


Welcome  to  UC  (Unix  Consultant)  version  3.23 
To  a  '#'  proii?)t,  please  type  in  your  questions 
about  the  UNIX  file  system  in  English. 

To  leave,  just  type  ' ^D'  or  ' (exit) ' . 

Hi. 

How  can  I  help  you? 

#  What  does  Is  -v  do? 

The  parser  produces; 

(ASKIO  (listenerlO  =  UC) 

(speakerlO  =  *USER*) 

(asked-forlO  =  (QUESTIONIO  (what-islO  =  STATE12?)))) 
(HAS-EFFECT21?  (ef  fect-of-COnin'.and21  =  STATE12?) 

(corranand-of-effect21  =  UNIX-LS-COMMANDO) ) 
(HAS-0PTI0N3  (options  =  -v-OPTIONO) 

(coinmand-of-option3  =  UNIX-LS-COMMANDO)  ) 


The  parser  understands  the  user’s  input  as  a  question  about  the  effects  of  the  UNIX-LS 
COMMANDO,  which  has  a  -v  option  (HAS-OPTION3). 


The  goal  analyzer  produces; 

( (HAS-GOAL-gaO  (planner-gaO  =  *USER*) 

(goal-gaO  = 

(KNOW-gaO?  (knower-gaO  =  *USER*) 

(fact-gaO  =  STATE12?) ) ) ) ) 


UCEgo ;  suggesting  the  plan; 

(PLANFOR71  (goals71  =  (HELPS  (helpeeS  =  *USER*)  (helperS 
(plan71  =  (SATISFY6  (need6  =  (KNOW-gaO?  &)) 

(actorG  =  UC) ) ) ) 

based  on  the  situation; 

(UC-HAS-GOAL63  (status63  =  ACTIVE)  (goal63  -  (HELPS  &) ) 
(HAS-GOAL-gaO  &) 


UC)  )  ) 
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UCEgo:  detected  the  goal: 

(UC-HAS-GOAL66  (goal66  =  (KNOW-gaO?  &) ) ) 
from  the  situation: 

(UC-HAS- INTENT ION 9  (intention9  =  (SATISFY6  &) )  (status9  =  ACTIVE) ) 


UCEgo  adopts  the  sub-goal  of  having  the  user  know  what  the  effects  of  Is  -v  are. 


UCEgo :  trying  to  find  effects  for  UNIX-LS -COMMANDO 

UCEgo:  unknown  relation: 

(HAS-OPTION3  &) 

UCEgo:  User  has  the  Misconception: 

(HAS-MISCONCEPTIONl  (confusedl  =  *USER*) 

(misconceptionl  =  (HAS-OPTION3  &) ) ) 

since 

(KNOW42  (fact42  =  (ALL3  {such-that3  = 

(HAS-OPTIONO?  (optionO  =  (ALL3  &)) 
(command-of-optionO  = 
SIMPLE-COMMANDO?) ) ) 
(all-type3  =  OPTIONO?))) 

(knower42  =  UC) ) 
and  since  the  user  believes: 

(HAS-OPTION3  (option3  =  -v-OPTIONO) 

(command-of-option3  =  UNIX-LS -COMMANDO ) ) 
which  involves  an  unknown  OPTION 

UCEgo:  suggesting  the  plan: 

(PLANFOR72 

(goals72  =  (HELPS  &) ) 

(plan72  =  (SATISFY7  (need?  = 

(KNOW59?  (knower59  =  *USER*) 

(fact59  =  (NEGATEl 

(negativel  = 
(HAS-OPTION3  &)))))) 

(actor?  =  UC) ) ) ) 
based  on  the  situation: 

(UC-HAS -GOAL 6 3  &) 

(HAS-MISCONCEPTIONl) 

UCEgo:  detected  the  goal: 

(UC-HAS-GOAL67  (goal67  =  (KNOW59?  &) ) ) 
from  the  situation: 

(UC-HAS-INTENTIONIO  (intentionlO  =  (SATISFY?  &)) 

(statuslO  =  ACTIVE)) 

UCEgo:  suggesting  the  plan: 

(PLANFOR73  (plan?3  = 

(TELLS  (propositions  =  (NEGATEl  &)) 
(listenerS-O  =  *USER*) 
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(speak.er5-0  =  UC)  )  ) 
(goal373  =  (KNOW59?  &))) 
based  on  the  situation: 

(UC -HAS -GOAL 6 7  &) 

The  generator  is  passed: 

(TELLS  &) 

Is  does  not  have  a  -v  option. 


Figure  3.17.  UC  session  showing  UC  handling  a  user  misconception. 


UC  detects  misconceptions  as  part  of  the  process  of  fulfilling  the  user’s  request.  In 
the  example  of  Figure  3.17,  UCEgo  detects  the  misconception  in  the  process  of  finding 
the  effects  of  Is  -v.  After  processing  by  the  parser/understander  and  goal  analysis  com¬ 
ponents  of  UC,  the  interpretation  of  the  user’s  query  is  that  the  user  wants  to  know  the 
effects  of  the  Is  command  (UNIX-LS -COMMANDO)  with  the  -v  option  (HAS- 
OPnON3).  In  retrieving  the  effects  of  the  command,  UCEgo  must  check  all  of  the  rela¬ 
tions  of  the  command.  This  process  leads  to  the  discovery  that  the  relation  HAS- 
OPnON3  does  not  correspond  to  anything  in  UC’s  knowledge  base.  When  such  an  unk¬ 
nown  relation  is  encountered,  UCEgo  tries  to  see  if  it  is  covered  by  UC’s  meta¬ 
knowledge.  In  this  case,  UC  has  the  meta-knowledge  that  UC  knows  (KNOW32)  all  of 
the  options  of  simple  commands.  Since  Is  is  a  simple  command,  UC  believes  *at  it 
knows  all  of  the  options  of  Is.  Because  -v  is  not  listed  among  Is’s  options  in  UC  s 
knowledge  base,  UC  concludes  that  it  must  be  a  user  misconception. 

After  detecting  the  misconception,  UCEgo  detects  a  plan  (PLANFOR56)  for  help¬ 
ing  the  user  that  involves  having  the  user  know  that  Is  does  not  have  a  -v  option.  This 
new  sub-goal  of  correcting  the  misconception  is  detected  by  the  if-detected  daemon 
shown  in  Figure  3.18.  This  results  in  UC  telling  the  user  that,  “Is  does  not  have  a  -v 

option.’’ 
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Figure  3.18.  If-detected  daemon  for  correcting  misconceptions. 


5.  Filling  Gaps  in  User  Knowledge 


A  major  difference  between  programs  that  purport  to  be  consultants  or  tutors  and 
typical  application  programs  is  the  fact  that  consultant/tutor  programs  typically  know 
more  about  their  domain  than  their  users.  This  leads  to  problems  when  users  of  a  consul¬ 
tant  system  do  not  know  enough  to  ask  the  right  questions.  A  tutoring  system  can  usually 
avoid  this  problem  by  properly  structuring  tutoring  sessions  or  by  not  providing  the  user 
with  opportunities  for  unconstrained  inquiry.  A  consultant  system,  however,  cannot  util¬ 
ize  either  of  these  methods.  It  must  be  able  to  handle  unconstrained  inquiries  from  the 
user  in  its  domain,  and  be  prepared  to  deal  with  users  that  do  not  know  enough  to  ask  the 
right  questions. 

One  type  of  difficulty  encountered  by  consultant  systems  in  dealing  with  users 
occurs  when  the  user  lacks  some  information  that  is  useful  for  the  user’s  task.  In  such 
cases,  the  consultant  should  volunteer  the  information  rather  than  waiting  for  the  user  to 
ask  for  it.  Volunteering  the  information  solves  the  bottleneck  problem  that  occurs  when 
the  user  never  asks  for  needed  information  because  the  user  does  not  realize  than  the 
information  is  necessary. 

5.1.  Different  kinds  of  Volunteered  Information 

In  order  to  be  able  to  volunteer  information,  a  consultant  system  must  do  three 
things: 
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1)  determine  that  it  would  be  helpful  for  the  user  to  know  some  information 

2)  deduce  whether  or  not  the  user  already  knows  the  information 

3)  inform  the  user  if  the  system  either  believes  that  the  user  does  not  know 
the  information  or  if  the  system  wants  to  remind  the  user  of  the  informa¬ 
tion 

The  kinds  of  information  that  might  be  volunteered  by  a  consultant  can  be  divided 
into  three  types:  warnings,  suggestions,  and  elaborations.  Warnings  are  provided  when 
the  consultant  believes  there  is  a  potential  problem  for  the  user.  Suggestions  are  given  to 
present  alternatives  and  methodological  hints  to  the  user.  Elaborations  involve  providing 
additional  information  that  is  relevant  to  the  user’s  query.  Each  type  of  volunteered 
information  is  described  in  greater  detail  below. 

5.2.  Warnings 


A  consultant  system  should  consider  providing  a  warning  to  the  user,  when  the  con¬ 
sultant  believes  that  there  may  be  a  problem  with  the  user’s  plans.  Two  factors  come 
into  play  when  deciding  whether  or  not  to  give  a  warning.  The  first  factor  is  the  likeli¬ 
hood  that  the  problem  will  actually  occur.  For  example,  if  the  user  wants  to  print  a  file, 
the  user’s  plan  may  fail  if  there  is  a  power  blackout  or  if  the  printer  is  out  of  ink.  The 
chances  of  a  problem  caused  by  a  power  blackout  are  so  unlikely  that  giving  such  a 
warning  would  be  unreasonable.  On  the  other  hand,  it  may  be  reasonable  to  warn  the 
user  about  the  printer  being  out  of  ink,  if  the  consultant  knows  that  the  printer  is  currently 
low  or  out  of  ink,  or  if  this  particular  printer  is  so  heavily  used  that  it  frequently  runs  out 
of  ink. 

Another  factor  in  deciding  whether  or  not  to  give  a  warning  to  the  user  is  the 
consultant’s  belief  about  whether  or  not  the  user  is  already  aware  of  the  potential  prob¬ 
lem.  Being  aware  of  the  problem  implies  that  the  user  both  knows  that  there  is  a  poten¬ 
tial  problem  with  this  type  of  plan,  and  knows  that  this  problem  may  arise  in  this  case.  If 
the  consultant  believes  that  the  user  is  already  aware  of  the  potential  problem,  then  the 
consultant  does  not  need  to  warn  the  user.  If  the  consultant  believes  that  the  user  knows 
about  this  class  of  problem,  but  might  not  apply  this  knowledge  in  this  particular  case, 
then  the  consultant  should  remind  the  user  with  a  warning.  In  some  cases,  the  potential 
problem  may  be  important  enough  that  the  consultant  may  wish  to  remind  the  user,  even 
though  the  user  is  already  aware  of  the  problem. 

Common  warnings  include  telling  the  user  about  a  plan  s  preconditions  that  are 
commonly  violated  and  telling  the  user  about  a  plan  s  deleterious  side-effects.  An  exam¬ 
ple  of  warning  the  user  about  a  commonly  violated  precondition  is: 


-98- 


User;  How  can  I  delete  the  directory  named  misc? 

UC:  Type ‘rmdir  misc’. 

However,  rmdir  works  only  if  the  directory  is  empty. 


In  the  example,  UC  warns  the  user  about  a  precondition  of  the  rmdir  plan,  namely 
that  the  directory  must  be  empty.  This  precondition  is  commonly  violated,  hence  it  is  a 
candidate  for  expressing  to  the  user.  This  can  be  contrasted  to  odier  preconditions  of 
rmdir  such  as  the  need  for  write  permission  on  the  directory  confining  the  directory  to 
be  deleted.  This  precondition  is  much  less  frequently  violated,  so  it  is  not  a  can^date  for 
expressing  to  the  user.  Such  frequency  information  is  stored  as  concerns  ([Luria,  1987]) 
by  the  UNIX  domain  planning  component  of  UC.  When  the  UNIX  domain  planner 
creates  a  plan,  it  passes  along  to  UCEgo  those  preconditions  that  have  a  high  degree  of 
concern.  UCEgo  then  decides  whether  or  not  to  warn  the  user  about  the  precondition 
depending  on  whether  or  not  KNOME  believes  that  the  user  already  knows  that  this  type 
of  problem  may  arise  in  this  such  plans.  Since  KNOME  does  not  model  the  user  s  ability 
to  apply  general  knowledge  to  individual  cases,  UCEgo  can  only  assume  that,  if  the  user 
knows  about  this  problem  in  general,  then  the  user  will  know  that  it  applies  in  this 
specific  case.  So  UCEgo  provides  a  warning  only  when  KNOME  believes  that  the  user 
does  not  know  about  the  precondition  to  the  plan. 


Warnings  about  a  plan’s  deleterious  side-effects  are  handled  in  a  similar  fashion. 
The  UNIX  domain  planner  stores  concerns  about  the  side-effects  of  plans  and  returns 
them  along  with  the  plan  that  it  produced.  In  the  following  example,  UC  warns  the  user 
about  one  of  mv’s  deleterious  side-effects,  namely  that  mv  will  overwrite  files: 


User:  How  can  I  move  the  file  named  new  to  the  file  named  old? 

UC:  Type  ‘mv  new  old’. 

However,  be  careful,  since  if  the  file  named  old  exists,  it  will  be  delet¬ 
ed. 


5.3.  Suggestions 

Suggestions  are  provided  by  a  system  to  present  alternative  plans  to  the  user  and  to 
present  methodological  hints  to  the  user.  A  trace  of  a  UC  dialog  in  which  UC  volunteers 
a  suggestion  to  the  user  is  shown  in  Figure  3.19. 


Welcome  to  UC  (Unix  Consultant)  version  3.23 
To  a  '#'  pron?>t,  please  type  in  your  questions 
about  the  xmix  file  system  in  English. 

To  leave,  just  type  ' or  ' (exit) '  . 

Hi. 

How  can  I  help  you? 

#  Who  is  on  the  system? 

I'm  sorry,  I  do  not  know  that. 

To  find  out,  type  'who' . 


Figure  3.19.  UC  session  showing  UC  volunteering  a  suggestion  to  the  user. 


Since  UC  was  not  programmed  with  direct  access  to  UNIX,  UC  does  not  know  who 
is  on  the  system.  Hence  UC  apologizes  to  the  user  in  order  to  be  polite.  However,  UC 
does  know  how  the  user  can  find  out  who  is  on  the  system,  namely  by  using  the  who 
command.  So,  if  UC  believes  that  the  user  does  not  already  know  about  the  who  com¬ 
mand,  UC  will  suggest  this  plan  to  the  user.  Figure  3.20  shows  the  daemon  that  detects 
the  sub-goal  of  having  the  user  know  how  to  find  out  something  that  the  user  wishes  to 
know  when  the  user  does  not  know  this  particular  plan  for  finding  out  the  required  infor¬ 
mation  (obviously,  the  user  does  know  one  plan  for  finding  out,  namely,  ask  UC). 
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Figure  3.20.  If-detected  daemon  that  suggests  how  to  find  out  information. 
In  general,  this  daemon  is  activated  in  the  following  situations: 


1)  UC  wants  to  help  the  user  (UC-HAS-GOALl) 

2)  the  user  wants  to  know  something  (HAS-GOALl) 

3)  there  is  a  specific  (tested  by  the  NOT  DOMINATE  1  test)  plan  for  finding 
out  (INFORMATION-EFFECT  1)  the  information 

4)  the  user  does  not  know  the  plan  (tested  by  the  TEST-NOT,  does-user- 
know?l,  which  represents  a  call  to  KNOME) 

In  such  situations,  the  daemon  asserts  that  a  plan  for  helping  the  user  is  to  adopt  the 
sub-goal  of  having  the  user  know  the  plan  for  finding  out  the  information. 

The  previous  example  shows  how  UCEgo  proceeds  when  it  fails  to  find  a  plan  for  a 
goal.  It  adopts  the  meta-goal  (see  Section  3.1)  of  finding  a  plan  for  that  goal.  In  this 
case,  UC  does  not  know  who  is  on  the  system,  so  it  adopts  the  meta-goal  of  knowing  a 
plan  for  finding  out  who  is  on  the  system.  UC’s  UNIX  domain  planner  returns  the  plan 
of  using  the  who  command,  which  UC  cannot  use,  because  it  does  not  have  direct  access 
to  UNIX.  However,  UC  can  suggest  this  plan  to  the  user  who  does  have  access  to  UNIX 
and  so  can  use  the  plan.  The  if-detected  daemon  shown  in  Figure  3.20  suggests  the  plan 
for  helping  the  user  of  adopting  the  sub-goal  of  having  the  user  know  the  who  plan. 
Note  that  the  daemon  only  suggests  this  plan  if  KNOME  believes  that  the  user  does  not 
already  know  about  who.  After  all,  it  is  possible  that  the  user  does  know  who,  but 
instead  decided  to  ask  UC  in  order  to  find  out  the  information  (a  plan  that  fails  in  this 
case).  An  extended  analysis  of  UC’s  processing  in  volunteering  these  types  of  sugges¬ 
tions  is  given  in  Section  5.5.  Some  other  examples  of  the  same  type  are  shown  in  Figure 
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3.21. 


Welcome  to  UC  (Unix  Consultant)  version  3.23 
To  a  '#'  pron?>t,  please  type  in  your  questions 
about  the  UNIX  file  system  in  English. 

To  leave,  just  type  ' ^D'  or  ' (exit) ' . 

Hi. 

How  can  I  help  you? 

#  What  is  Chin's  office? 

I'm  sorry,  I  do  not  know  that. 

To  find  out,  type  'finger  chin' . 

#  What  is  the  inode  of  the  file  named  junk? 

I'm  sorry,  I  do  not  )cnow  that. 

To  find  out,  type  'Is  -i'  . 

#  How  can  I  print  a  file  on  the  laser  printer? 

Use  Ipr  -Plz . 

Don't  forget  to  file  the  printer  output  in  the  boxes. 


Figure  3.21.  UC  session  showing  suggestions  by  UC. 


The  last  example  shows  a  reminder  type  suggestion.  Reminders  are  given  when  the 
system  believes  that  the  user  already  knows  some  information,  but  the  system  also 
believes  that  the  user  is  likely  to  forget  or  ignore  the  information.  In  such  cases,  the  sys¬ 
tem  issues  a  reminder.  In  this  example,  KNOME  believes  that  the  user  already  knows 
about  filing  printer  output  in  the  boxes,  so  normally,  UCEgo  would  abandon  the  pal  of 
suggesting  that  to  the  user.  However,  in  this  case  it  is  likely  that  the  user  will  shirk  this 
duty,  so  UCEgo  decides  to  provide  the  suggestion  as  a  reminder. 

In  general,  to  issue  a  reminder  type  suggestion  requires  that  a  system  perform  the 
following: 

1)  detect  some  useful  information  for  suggestion  to  the  user 

2)  determine  that  the  user  is  likely  to  forgetAgnore  the  information 

3)  inform  the  user  if  the  system  believes  that  the  user  needs  to  be  reminded 
of  the  information 


w 
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Whether  a  user  is  likely  to  forget  or  ignore  information  is  represented  in  UC  in  a 
fashion  similar  to  concerns  ([Luria,  1987]).  Facts  that  users  are  likely  to  forget  or  ignore 
are  marked  as  needing  reminding.  Since  UC  will  provide  a  reminder  type  suggestion 
regardless  of  whether  the  user  already  knows  the  information,  there  is  no  need  to  check 
for  this  as  in  other  types  of  suggestions.  On  the  other  hand,  UC  does  need  to  check 
whether  it  has  direct  evidence  during  the  current  session  that  the  user  is  cognizant  of  the 
information.  So,  if  the  user  has  previously  mentioned  the  information,  or  if  UC  has  pre¬ 
viously  reminded  the  user  of  the  information,  then  UC  does  not  provide  a  reminder  type 
suggestion  to  the  user. 

5.4.  Elaborations 

Elaborations  are  given  when  the  user  asks  a  simple  yes/no  question  and  the  system 
volunteers  more  information.  Volunteering  additional  information  in  such  cases  has  been 
termed  over-answering  by  [Wahlster  et  al.,  1983],  who  implemented  over- answering  in 
the  HAM-ANS  natural  language  system.  An  example  of  elaboration  produced  by  UC  is 
shown  in  Figure  3.22. 


Welcome  to  UC  (Unix  Consultant)  version  3.23 
To  a  proit^Jt,  please  type  in  your  questions 
about  the  UNIX  file  system  in  English. 

To  leave,  just  type  ' *D'  or  ' (exit) ' . 

Hi. 

How  can  I  help  you? 

#  Is  rn  used  to  rename  files? 

No,  m  is  used  to  read  news. 

To  rename  a  file  to  another  file,  use  mv. 

For  example,  to  rename  the  file  named  foo  to  the  file  named  fool, 
type  'mv  foo  fool' . 


Figure  3.22.  UC  dialog  showing  an  elaboration  in  UC’s  response  to  the  user. 


Elaborations  such  as  the  above  require  that  the  system  recognize  that  the  user  not 
only  has  the  goal  of  knowing  whether  rn  is  used  to  rename  files,  but  also  that  this  goal  is 
a  sub-goal  of  two  possible  parent  goals,  namely  knowing  the  effects  of  the  rn  command 
and  knowing  how  to  rename  files.  In  UC,  these  deductions  are  made  by  UC’s  goal 
analysis  component,  PAGAN.  After  PAGAN  has  deduced  the  user  s  goals,  UCEgo 
proceeds  by  adopting  all  of  the  user’s  possible  goals.  In  cases  where  the  answer  is  yes, 
both  potential  parent  goals  are  satisfied  by  the  simple  answer  of  yes,  so  all  three  goals 
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can  be  merged  into  a  single  goal  (see  Section  3.2),  and  no  elaboration  is  needed.  How¬ 
ever,  in  the  above  example,  a  no  answer  only  satisfies  the  user  s  unmediate  goal  of  know¬ 
ing  whether  rn  is  used  to  rename  files  and  does  not  satisfy  either  possible  parent  goal.  In 
such  cases,  UCEgo  proceeds  to  process  both  parent  goals  and  produces  answers  to  satisfy 
both.  When  KNOME  believes  that  the  user  already  knows  one  of  the  answers,  only  the 
other  answer  is  given  to  the  user. 

This  goal-based  approach  to  elaboration  can  be  compared  to  the  over-answering 
methodology  of  HAM-ANS.  HAM-ANS  used  specific  strategies  such  as  filling  optional 
deep  case-slots  in  the  case-frame  associated  with  a  verb  used  in  the  user  s  request.  The 
problem  with  such  non-goal-based  approaches  is  that  diey  are  prone  to  volunteering 
information  that  the  user  may  not  actu^ly  be  interested  in.  For  example,  when  the  user 
asks  HAM-ANS,  “Has  a  yellow  car  gone  by?”  HAM-ANS  elaborates  upon  the  where 
case-slot  to  produce  the  answer,  “Yes,  one  yellow  one  on  Hartungstreet”  This  is  a  good 
answer  if  the  user  were  actually  interested  in  where  the  yellow  car  passed  by.  However, 
if  the  user  were  interested  in  how  long  ago  the  car  passed  by,  then  an  elaborative  answer 
like  “Yes,  fifteen  minutes  ago,”  would  be  much  better.  Likewise,  if  the  user  were 
interested  in  foUowing  the  yellow  car,  then  a  better  answer  would  be,  “Yes,  north  on 
Hartungstreet.” 

In  order  to  choose  between  such  different  elaborations,  an  analysis  of  the  user  s 
goals  is  needed.  For  example,  if  the  user  had  prefaced  the  question  by  the  statement, 
“My  friend  is  supposed  to  pick  me  up  here,”  then  an  analysis  of  the  user  s  goals  would 
show  that  the  user  is  probably  more  interested  in  how  long  ago  the  yellow  car  passed  by. 
On  the  other  hand,  if  the  user  is  a  police  officer  chasing  a  vehicle,  then  the  user  is  prob¬ 
ably  interested  in  following  the  yellow  car.  So,  deciding  how  to  elaborate  a  yes/no 
answer  requires  a  goal-based  elaboration  strategy  such  as  the  one  used  in  UC. 

Besides  being  useful  for  deciding  exactly  how  to  elaborate  a  yes/no  answer,  a  goal- 
based  strategy  also  tells  the  system  whether  or  not  it  is  useful  to  elaborate  at  all.  For 
example,  when  the  user  asks  UC,  “Is  compact  used  to  compact  files?”  then  a  simple 
answer  of  “Yes,”  is  quite  sufficient.  There  is  no  need  for  UC  to  elaborate  on  this 
answer,  because  it  addresses  all  of  the  user’s  possible  parent  goals.  Similarly,  in  the 
hypothetical  dialog  with  a  HAM-ANS-like  system  shown  in  Figure  3.23,  there  is  no  need 
to  elaborate  the  answer  to  the  user’s  question,  “Has  a  yellow  car  gone  by?”  since  an  ela¬ 
boration  would  not  help  to  satisfy  the  user  s  goals. 
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User:  I  need  the  results  from  your  checkpoint  for  the  Cannonball  Run  auto 

race. 

Has  a  black  Porsche  911  Turbo  gone  by? 

System:  Yes. 

User:  Has  a  blue  pickup  gone  by? 

System:  Yes. 

System:  Has  a  yellow  car  gone  by? 

User:  No. 


Figure  3.23.  Hypothetical  dialog  in  which  elaboration  is  not  needed. 


5.5.  An  Example  Trace 

To  see  in  greater  detail  how  UCEgo  decides  to  volunteer  information,  consider  the 
annotated  trace  of  a  UC  session  shown  in  Figure  3.24  below. 


Welcome  to  UC  (Unix  Consultant)  version  3.23 
To  a  '#'  pron^Jt,  please  type  in  your  questions 
about  the  UNIX  file  system  in  English. 

To  leave,  just  type  ' "D'  or  ' (exit) ' . 

Hi. 

How  can  I  help  you? 

#  What  is  chin's  phone  number? 

The  parser  produces : 

(ASK9  (listener9  =  UC) 

(speaker9  =  *USER*) 

(asked-for9  = 

(QUESTION9 

(what-is9  =  (STATE-OF-USERl?  (user-statel  =  USER-PHONEO) 

(state-userl  =  USER9) ) ) ) ) ) 

(HAS-USER-NAME2  (user-name2  =  chin)  (named-user2  =  USER9) ) 
(HAS-NAME27  (name27  =  chin)  (named-obj27  =  PERSON36) ) 

The  goal  analyzer  produces: 

( (HAS-GOAL-gaO  (planner-gaO  =  *USER*) 

(goal-gaO  = 

(KNOW-gaO?  (knower-gaO  =  *USER*) 
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(fact-gaO  =  (STATE-OF-USERl?  &)))))) 


The  user’s  goal  is  to  know  STATE-OF-USERl,  which  represents  the  phone  number  of 
USER9  who  has  name  “chin.” 


This  part  is  typical;  it  leads  up  to  UCEgo  adopting  the  goal  of  having  the  user  know 
Chin’s  phone  number. 


UCEgo  detects  the  following  concepts: 

(UC-HAS-GOAL59  &) 

and  asserts  the  following  concept  into  the  database: 
(UC-is-statel  (is-statel  =  (STATE-OF-USERl?  &))) 


UCEgo  calls  the  procedure  UC-is- state  to  try  to  look  up  the  state  information.  The  next 
trace  message  shows  that  UC-is-state  failed  to  find  the  information. 


UCEgo:  UC  does  not  know  STATE-OF-USERl? 

UCEgo:  detected  the  goal: 

(UC-HAS-GOAL60 

(goaieO  =  (KNOW54?  (knower54  =  UC) 

(fact54  =  (STATE-OF-USERl?  &))))) 

from  the  situation: 

(KNOW53  (knower53  =  UC) 

(truth-val53  =  FALSE) 

(fact53  =  (STATE-OF-USERl?  &))) 

(UC-HAS-GOAL59  &) 


Since  UC  wants  the  user  to  know  Chin’s  phone  number,  and  UC  does  not  know  this 
information,  UC  adopts  the  meta-goal  (UC-HAS-GOAL60)  of  finding  out  this  informa¬ 
tion  (i.  e.  adopting  the  goal  of  having  UC  —  rather  than  the  user  as  in  the  previous  UC- 
HAS-GOAL59  —  know  Chin’s  phone  number).  Such  meta-goals  are  discussed  in  Sec¬ 
tion  3.1. 
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UCEgo  detects  the  following  concepts; 

(UC- HAS -GOAL 60  &) 

and  asserts  the  following  concept  into  the  database: 
(UC-is-state2  {is-state2  =  (STATE -OF-USERl?  &))) 


The  procedure  UC-is-state  is  tried  again,  only  this  time  UC’s  goal  is  for  UC  to  know  the 
answer  rather  than  the  user.  However,  the  result  is  the  same;  UC-is-state  does  not  have 
the  information. 


UCEgo:  suggesting  the  plan: 

(PLANFOR64  (plan64  =  (APOLOGIZE2  (apology2  =  (KNOW53  &)) 

{listener2-2  =  *USER*) 
(speaker2-2  =  UC) ) ) 

(goals64  =  (BE-POLITE5  (polite-to5  =  *USER*) 

(is-polite5  =  UC) ) ) ) 

based  on  the  situation: 

(KNOW53  &) 

(HAS-GOAL-gaO  &) 

(UC-HAS-GOAL54  (status54  =  ACTIVE)  (goal54  =»  (BE-POLITE5  &) ) ) 


Since  UC  wants  to  be  polite,  and  does  not  know  what  the  user  wishes  to  find  out,  UCEgo 
suggests  the  plan  of  apologizing  to  the  user  for  not  knowing  in  order  to  be  polite  to  the 

user. 


UCEgo  detects  the  following  concepts: 

(UC-HAS-GOAL54  &) 

(PLANFOR64  &) 

and  asserts  the  following  concept  into  the  database: 
(UC-HAS-INTENTIONll  (intentionll  =  (APOLOGIZE2  &)) 

(statusll-0  =  ACTIVE) ) 

UCEgo  detects  the  following  concepts: 
(UC-HAS-INTENTIONll  &) 

and  asserts  the  following  concept  into  the  database: 
{UCexpress3  (gen-prop3  =  (APOLOGIZE2  &)  )  ) 

The  generator  is  passed: 

(APOLOGIZE2  &) 

I'm  sorry,  I  do  not  )cnow  that. 


-  107- 


The  actual  apology. 


UCEgo:  do  not  know  a  single  planfor  the  foreground  goal: 
(UC- HAS -GOAL 60  &) 
so  adding  the  meta-goal: 

(UC-HAS-GOAL61  (goal61  =  (KNOW55?  (knowerSS  =  UC) 

(factSS  =  ACTION13?) ) ) ) 

(PLANFOR65? 

(goals65  =  (INFORMATION-EFFECTl? 

(desired-infol  =  (STATE-OF-USERl?  &)) 

( informant 1  =  UC) ) ) 

(plan65  =  ACTION13?)) 


Since  UC  does  not  know  of  any  planfor  satisfying  the  goal  of  knowing  Chin’s  phone 
number  (UC-HAS-GOAL60),  it  adopts  the  meta-goal  of  knowing  (KNOW55)  a  plan 
(ACTION13)  for  finding  out  (INFORMATION-EFFECTl)  the  information. 


UCEgo  detects  the  following  concepts: 

{PLANFOR65?  &) 

(UC-HAS-GOAL61  &) 

and  asserts  the  following  concept  into  the  database: 
(UNIX-planner2  (user-goals2  =  (INFORMATION-EFFECTl?  &) ) ) 


UCEgo  calls  the  UNIX  domain  planner  to  find  a  plan  for  finding  out  Chin’s  phone 
number. 


The  planner  is  passed: 

( ( INFORMAT ION-EFFECT 1 ?  & ) ) 

The  planner  produces : 

(PLANFOR330  (goals330  =  (INFORMATION-EFFECTl?  &)) 

(plan330  =  (UNIX-FINGER-COMMANDO 

(f inger-userO  =  USER9) ) ) ) 

( F INGER- HAS -FORMAT  0 

(FINGER-HAS-FORMAT-COmmandO  =  (UNIX-FINGER-COMMANDO  &)) 
(FINGER-HAS-FORMAT-formatO  = 

( F INGER-FORMATO 
(f inger-name-argO  =  chin) 

(FINGER-FORMAT-UNIX-COMMAND-FORMAT-StepO  =  finger) ) ) ) 

( HAS -COMMAND -NAME 100 

(HAS-COMMAND-NAME-named-ob jlOO  =  (UNIX-FINGER-COMMANDO  &) ) 
(HAS-COMMAND-NAME-namelOO  =  finger) ) 
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The  UNIX  domain  planner  returns  the  plan  of  using  the  finger  command. 


UCEgo  detects  the  following  concepts: 

(UC -HAS -GOAL 6 2  &) 

(PLANFOR330  &) 

and  asserts  the  following  concept  into  the  database: 
(UC-HAS-INTENTION14  (intentionl4  =  (UNIX-FINGER-COMMANDO  &)) 

(statusl4  =  ACTIVE) ) 


UC  intends  to  finger  Chin,  but  it  cannot,  because  has  not  been  programmed  to  have  direct 
access  to  UNIX. 


UCEgo:  suggesting  the  plan: 

(PLANFOR67  (goals67  =  (HELPS  &)) 

(plan67  =  (SATISFY8  (actorS  =  UC) 

(needs  = 

(Kt'IOWSS?  (factSo  =  (PLANFOR350  &)) 
(knowerSe  =  *USER*) ) ) ) ) ) 

based  on  the  situation: 

(UC-HAS-GOAL56  &) 

(PLANFOR330  &) 

(HAS-GOAL-gaO  &) 


Since  UC  wants  to  help  the  user  (UC-HAS-GOAL56),  and  the  user  wants  to  know  Chin’s 
phone  number  (HAS-GOAL-gaO),  and  finger  is  a  planfor  finding  out  Chin’s  phone 
number,  UCEgo  suggests  that  a  plan  for  helping  the  user  is  for  the  user  to  know  that 
finger  is  a  planfor  finding  out  Chin’s  phone  number.  This  is  the  if-detected  daemon  that 
volunteers  information. 


As  in  processing  typical  queries,  UCEgo  suggests  the  plan  of  telling  the  user  in  order  to 
achieve  the  goal  of  having  the  user  know  the  information. 


The  generator  is  passed: 
(TELLS  &) 
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To  find  out,  type  'finger  chin' . 


Figure  3.24.  UC  session  showing  UC  providing  a  suggestion  to  the  user. 


6.  Conclusion 


6.1.  Summary 

This  chapter  has  addressed  the  problems  of  where  goals  come  from  and  how  an 
intelligent  agent  can  detect  the  right  goals.  These  are  important  problems  which  have  not 
been  systematically  addressed  by  previous  planners,  whose  high  level  goals  were  all  pro¬ 
vided  by  their  human  operators.  In  order  to  be  independent,  a  system  needs  be  able  to 
detect  the  right  goals,  which  the  agent  can  then  plan  to  achieve,  and  in  this  way  act  intel¬ 
ligently  in  response  to  changes  in  its  environment. 

The  ultimate  source  of  goals  is  an  agent’s  themes,  which  represent  the  agent  s  inter¬ 
nal  motivations.  However,  themes  only  provide  very  general  goals,  such  as  helping  the 
user,  preserving  oneself,  and  being  polite.  More  specific  goals  are  detected  by  an  agent 
as  sub-goals  of  these  higher  level  goals  (or  as  sub-goals  of  sub-goals).  Other  types  of 
specific  goals  are  detected  when  goals  or  plan  steps  are  found  to  interact  (either  posi¬ 
tively  or  negatively).  In  these  cases,  an  agent  detects  meta-goals  for  dealing  with  the 
interaction  among  the  agent’s  goals. 

Specific  goals  are  detected  by  a  system  in  particular  situations.  Since  a  consultant 
system’s  main  task  is  to  impart  knowledge  to  its  user,  situations  in  which  the  user  either 
lacks  knowledge  or  has  incorrect  information  (misconceptions)  are  the  most  important 
types  of  situations  for  UC’s  agent,  UCEgo.  Other  important  types  of  situations  include 
those  in  which  UC’s  goals  interact  either  negatively  by  conflicting,  or  positively  by  over¬ 
lapping.  In  such  situations,  UC  detects  meta-goals  for  dealing  with  the  goal  interaction. 

Situations  are  difficult  to  detect  since  they  can  consist  of  arbitrary  sets  of  internal  or 
external  states.  For  example,  an  agent  may  have  the  relatively  high  level  goal  of  having 
money  (which,  in  turn,  is  a  sub-goal  of  other  even  higher  level  goals  or  themes).  This 
agent  may  even  have  various  scriptal  plans  for  achieving  this  goal,  such  as  borrowing 
money,  getting  a  job,  winning  the  money  by  gambling,  etc.  However  consider  what 
might  happen  if  an  eccentric  billionaire  comes  up  to  the  agent  and  tells  the  agent,  “I  will 
give  you  a  million  dollars,  if  you  will  stand  on  your  head  whenever,  during  the  next 
month,  you  hear  an  electronic  wristwatch  beep,  and  the  sun  happens  to  be  shining.  In 
this  case,  the  agent  will  detect  the  new  sub-goal  of  doing  a  headstand  in  situations  in 
which  the  sun  is  shining  and  there  is  a  beep  from  an  electronic  wnstwatch.  Of  course, 
the  condition  could  be  almost  anything,  so  variants  of  this  scenario  will  lead  an  apnt  to 
detect  new  sub-goals  in  almost  arbitrary  situations.  This  arbitrary  nature  of  situations  in 
which  agents  might  detect  new  goals,  makes  the  goal  detection  process  extremely 
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difficult. 

My  approach  to  efficiently  detecting  situations  (in  particular,  those  that  lead  an 
agent  to  detect  new  goals)  is  to  encode  situations  using  if-detected  daemons.  These  dae¬ 
mons  are  in  essence  tiny  inference  engines  that  look  for  particular  types  of  situations,  and 
add  inferences,  such  as  new  goals  for  the  agent,  when  they  detect  a  matching  situation. 

6.2.  Problems 

UCEgo  only  deals  with  a  small  subset  of  potential  situations  which  might  lead  an 
agent  to  detect  new  goals.  In  particular,  UCEgo  is  concerned  with  situations  related  to 
the  state  of  knowledge  of  its  user,  since  UC’s  main  purpose  is  to  provide  information  to 
its  user.  In  other  domains,  agents  will  need  to  concentrate  on  other  types  of  situations. 
For  example,  an  intelligent  agent  for  driving  a  car  will  need  to  concentrate  more  on  the 
locations  of  other  cars  and  road  hazards  than  on  its  user.  It  is  not  clear  whether  the 
methodologies  demonstrated  in  UCEgo  can  be  extended  to  cover  other  domains  that  have 
a  different  emphasis  on  the  types  of  situations  that  can  lead  an  intelligent  agent  to  detect 
new  goals  (although,  I  do  believe  these  methodologies  are  extensible). 

One  of  the  main  deficiencies  of  UCEgo  is  that  it  does  not  have  a  hierarchy  of  situa¬ 
tion  classes.  One  would  like  such  a  hierarchy  in  order  to  more  efficiently  encode  related 
situations.  A  system  that  had  such  a  hierarchy  could  look  for  the  most  specific  matching 
situation,  and  detect  the  specific  goal  for  that  situation.  In  case  where  there  are  no 
matching  specific  situations,  the  agent  could  fall  back  on  more  general  situations  and  the 
relatively  more  general  goals.  This  deficiency  shows  up  in  some  of  UCEgo’s  goal  detec¬ 
tion  situations  as  a  lack  of  generality  in  the  encoded  situations.  Many  of  UCEgo’s  situa¬ 
tions  tend  to  be  extremely  specific,  partly  because  these  are  more  efficient  than  general 
situations.  A  hierarchy  of  situation  classes  would  allow  a  system  to  retain  specific  situa¬ 
tions  for  efficiency  as  well  as  have  more  general  situations  for  wider  coverage. 

An  important  problem  that  UCEgo  does  not  address,  is  how  to  add  new 
situation/goal  pairs  to  its  goal  detection  mechanism.  This  problem  involves  not  only 
learning  new  situation/goal  pairs,  but  also  reasoning  about  how  they  might  generalize. 
For  example,  an  agent  might  learn  that  if  it  sees  a  particular  tree  catch  fire,  then  it  should 
adopt  the  goal  of  extinguishing  the  fire.  The  agent  might  then  generalize  this  to  all  trees 
fires,  but  it  should  not  generalize  this  to  ail  fires  including  useful  fires  such  as  stovetop 
burners.  Learning  new  goal  detection  situations  is  an  important  facet  of  an  intelligent 
agent. 


-  111- 


Chapter  IV 

Plan  Selection  &  Execution 

After  UCEgo  has  detected  its  own  goals,  it  must  plan  for  those  goals  and  then  exe¬ 
cute  the  resultant  plan.  UCEgo  selects  different  plans  according  to  what  is  appropriate 
for  the  current  situation.  Plans  may  contain  sub-goals,  which  are  then  recursively 
satisfied  by  UCEgo.  This  chapter  describes  the  processes  of  plan  selection  and  then  exe¬ 
cution  in  UCEgo. 


1.  Introduction 

Natural  language  systems  act  primarily  by  communicating  with  the  user.  These 
communicative  actions  are  called  speech  acts  ([Austin,  1962]  and  [Searle,  1969]).  A 
planner  that  produces  plans  consisting  of  speech  acts  has  somewhat  different  require¬ 
ments  than  other  types  of  planners.  First  of  all,  speech  act  planners  need  to  perform  in 
real  time  in  order  to  carry  out  a  dialog  with  the  user.  This  implies  that  such  planners 
need  to  avoid  inefficient  search  and  backtracking  by  using  real  world  knowledge  to  guide 
the  planning  process. 

1.1.  Other  Planners 


Planning  has  a  long  history  in  AI,  starting  from  its  origins  as  search  within  a  prob¬ 
lem  space.  In  the  GPS  means-ends  analysis  formalism  of  [Newell  and  Simon,  1963],  a 
planner  searches  for  a  sequence  of  operators  that  allows  the  planner  to  move  from  an  ini¬ 
tial  state  in  the  problem  space  to  the  goal  state  of  the  planner.  STRIPS  ([Fikes  and  Nils¬ 
son,  1971])  is  an  early  example  of  a  planner  based  on  means-ends  analysis.  ABSTRIPS 
([Sacerdoti,  1974])  extended  the  formalism  to  work  in  hierarchical  problem  spaces. 
ABSTRIPS  broke  down  a  planning  problem  into  a  hierarchy  of  sub-problems  and  solved 
each  sub-problem  independently.  Since  sub-problems  may  not  actually  be  independent, 
planners  were  developed  by  [Sussman,  1975],  [Tate,  1975],  [Warren,  1974],  [Waldinger, 
1977],  [Sacerdoti,  1977],  [Stefik,  1980],  and  others,  that  could  handle  planning  when  die 
ordering  of  plan  steps  is  critical  to  the  success  of  a  plan.  KAMP  ([Appelt,  1981])  applied 
this  type  of  planner  to  the  problem  of  planning  natural  language  utterances.  KAMP 
planned  English  sentences  from  the  speech  act  level  down  to  selection  of  actual  words. 

The  previous  types  of  planners  develop  plans  from  scratch.  This  presents  a  prob¬ 
lem,  since  such  planning  is  computationally  expensive.  For  example,  it  was  not  unusual 
for  icAMP  to  take  several  hours  to  plan  a  complex  utterance.  Indeed,  Appelt  developed 
the  TELEGRAM  unification  grammar  ([Appelt,  1983])  to  improve  the  efficiency  and 
modularity  of  planning  at  the  linguistic  level.  Developing  plans  from  scratch  usmg 
“weak  methods”  such  as  search  and  theorem-proving  leads  to  inefficient  back-tracking 
and  computationally  expensive  checking  of  preconditions  for  every  plan  step.  These 
methods  do  not  take  advantage  of  available  domain  knowledge  about  the  types  of  plans 
that  are  applicable  in  different  situations. 
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Another  problem  with  general  purpose  planners  that  use  weak  methods  is  that 
their  complexity  is  not  needed  in  planning  speech  acts.  The  OSCAR  speech  act  planner 
([Cohen,  1978])  showed  that  a  very  simple  planner  that  did  not  backtrack  was  sufficient 
for  planning  basic  speech  acts.  Although  OSCAR  did  not  actually  produce  natural 
language  output,  it  did  plan  speech  acts  at  the  concepuial  level  in  enough  detail  to 
demonstrate  the  computational  theory  of  speech  act  generation  devised  by  [Cohen  and 
Perrault,  1979].  However,  since  OSCAR  did  not  have  to  produce  speech  acts  in  real  time 
in  order  to  sustain  a  dialog  with  a  user,  it  did  not  worry  about  how  to  plan  efficiently. 
Given  a  goal,  OSCAR  merely  looped  through  an  ordered  list  of  all  potential  actions  until 
it  found  one  whose  effects  matched  the  goal.  Only  after  deciding  upon  an  action  would 
OSCAR  test  the  preconditions  of  the  plan  and  adopt  as  sub-goals  any  preconditions  that 
OSCAR  did  not  beUeve  to  already  be  true.  If  OSCAR  could  not  satisfy  a  precondition 
sub-goal,  then  it  failed  in  planning  since  it  did  not  backtrack  to  try  different  actions.  The 
fact  that  OSCAR  worked  fairly  well  despite  this  seemingly  severe  limitation,  shows  that 
planning  speech  acts  does  not  usually  require  complex  planning. 

An  alternative  to  planning  from  scratch  using  ‘  weak  methods  is  presented  by 
[Schank  and  Abelson,  1975]  in  their  theory  of  scripts  and  plans.  In  their  theory,  a  script 
consists  of  a  very  specific  series  of  steps,  while  a  plan  is  more  abstract  and  includes  other 
components,  such  as  preconditions  on  the  use  of  the  plan.  The  TALb-bPIN  story  genera¬ 
tor  ([Meehan,  1976],  [Meehan,  1981])  implemented  this  theory  to  produce  plans  for  die 
charactere  in  its  stories.  [Friedland,  1980]  and  [Friedland  and  Iwasaki,  1985]  describe 
the  MOLGEN  and  SPEX  planners,  which  extended  the  idea  of  scripts  and  plans  into  a 
hierarchy  of  skeletal  plans.  Skeletal  plans  are  pre-stored  plans  whose  plan-steps  may 
vary  in  generality  from  specific  actions  as  in  scripts  to  abstract  sub-goals.  They  are  simi¬ 
lar  to  the  MACROPs  of  STRIPS  and  the  chunks  of  [Rosenbloom  and  Newell,  1982]. 
However,  the  latter  systems  emphasized  learning  chunks  or  MACROPs  rather  than  the 
selection  and  instantiation  of  abstract  plans.  In  a  similar  vein,  [Carbonell,  1986], 
[Kolodner  et  al.,  1985],  [Alterman,  1986],  and  [Hammond,  1986]  have  worked  on  adapt¬ 
ing  previous  plans  to  new  situations  using  techniques  such  as  analogical  reasoning,  case- 
based  reasoning,  and  utilization  of  a  knowledge  hierarchy  to  generalize  old  plan-steps 
and  then  respecify  them  to  form  new  plan-steps. 

Using  prestored  skeletal  plans  makes  for  a  much  more  efficient  planner  than  one 
that  has  to  plan  from  scratch  using  weak  methods.  However,  the  use  of  prestored  plans 
presents  a  different  efficiency  problem:  how  to  find  the  right  plan  for  a  specific  situation. 
TALE-SPIN  indexed  scripts  and  plans  under  the  goal  of  the  script/plan  and  then  looped 
through  all  possibilities,  checking  the  most  specific  scripts  first,  until  a  workable  plan  was 
found.  Similarly,  MOLGEN  and  SPEX  only  looked  at  the  UTILITY  slot,  i.  e.  the  goal, 
of  the  skeletal  plan.  Since  skeletal  plans  of  MOLGEN  and  SPEX  did  not  have  precondi¬ 
tions,  the  planners  could  not  even  consider  a  plan’s  preconditions  to  eliminate  unsuitable 
plans.  Instead,  the  planners  considered  all  skeletal  plans  that  fit  the  goal  and  returned  all 
proper  instantiations  of  those  plans  for  the  user  s  consideration. 

[Hendler,  1985]  describes  SCRAPS,  a  planner  that  used  marker-passing  to  help 
make  more  efficient  choices  during  planning.  The  marker-passing  mechanism  detected 
plan  choices  that  might  result  in  intra-plan  sub-goal  conflicts  early  in  the  plannmg  pro¬ 
cess.  The  planner  could  then  avoid  the  potential  conflict  by  choosing  an  alternative  and 
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hence  avoid  inefficient  backtracking.  For  example,  SCRAPS  was  able  to  avoid  back¬ 
tracking  while  planning  in  the  following  situation: 

You  are  on  a  business  trip  (in  a  distant  city).  You  wish  to  purchase  a  cleaver. 


By  passing  markers  from  BUYING,  *ME*,  and  CLEAVER- 27,  SCRAPS  found  the 
following  intersection  path: 

BUYING  TAKE-TRIP  PLANE  BOARDING  WEAPONS- 

CHECK  -4  IF  you  go  through  WEAPONS-CHECK  with  a  WEAPON,  you  get 

arrested  <-  WEAPON  CLEAVER  ^  CLEAVER-27 

This  path  was  then  evaluated  to  determine  that  it  represents  a  negative  interaction, 
because  it  is  a  “bad  thing”  to  get  arrested.  As  a  result,  SCRAPS  ruled  out  the  choice  of 
taking  a  PLANE  (taking  a  BUS  or  TRAIN  instead),  and  avoids  the  backtracking  that 
would  be  required  if  the  planner  had  chosen  to  take  a  PLANE.  One  of  the  problems  with 
such  a  scheme  is  the  length  of  the  marker-passing  path  needed  to  detect  important  inter¬ 
sections.  As  longer  paths  are  considered,  there  are  more  and  more  spurious  intersections. 
If  a  marker-passer  were  to  consider  only  shon  paths,  then  would  run  the  risk  of  missing 
important  longer  path-length  intersections.  With  a  path  length  of  eight  as  in  the  previous 
example,  any  reasonably  large  knowledge  base  would  produce  a  very  large  number  of 
intersections,  most  of  which  would  be  spurious.  Even  if  marker-passing  were  imple¬ 
mented  in  parallel,  and  all  of  the  resulting  intersections  checked  in  parallel,  it  is  uncertain 
whether  it  would  be  more  efficient  to  plan  using  marker-passing  or  simply  to  plan  in 
parallel  (e.  g.  a  planner  could  consider  traveling  by  PLANE,  BUS,  and  TRAIN  in  the 
previous  example  in  parallel,  and  then  evaluate  the  best  plan  later).  With  current  serial 
machines,  marker-passing  would  undoubtedly  be  less  efficient. 

Another  problem  with  SCRAPS  is  that  it  ignores  other  criteria  for  making  choices 
besides  potential  negative  sub-goal  interactions.  For  example,  choosing  among  the  vari¬ 
ous  travel  plans  in  Hendler’s  example  should  depend  on  much  more  than  buying  a 
cleaver.  One  would  not  want  to  take  a  bus  or  train  if  the  business  trip  in  the  distant  city 
were  on  the  opposite  coast  of  the  United  States.  Choice  criteria  such  as  the  distance  of 
the  trip  are  not  preconditions  in  the  sense  that  one  could  still  take  a  bus  or  train  for  long 
distance  travel,  although  one  would  not  want  to  do  so,  unless  one  suffered  from  fear  of 
flying  or  lacked  the  money  for  a  plane  ticket.  In  fact,  most  people  would  rather  abandon 
the  goal  of  buying  a  cleaver,  rather  than  abandon  the  plan  of  taking  the  plane  home  from 
a  distant  city.  Of  course,  most  people  in  that  situation  would  fix  their  plans  by  mailing 
the  cleaver  home  or  putting  it  in  checked  baggage  (to  avoid  going  through  weapons- 
check  with  the  cleaver).  However,  the  latter  is  not  a  fair  criticism  of  SCRAPS,  since 
SCRAPS  was  not  programmed  with  the  knowledge  needed  to  make  such  plan  fixes. 

1.2.  Planning  in  UCEgo 

UCEgo  attacks  the  problem  of  efficient  planning  of  speech  acts  in  several  ways. 
First  of  all,  like  OSCAR,  UCEgo  uses  a  very  simple  planner  that  avoids  inefficient 
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backtracking.  Secondly,  like  Meehan’s  TALE-SPIN,  Friedland  s  MOLGEN  planner,  and 
Iwasaki’s  SPEX,  UCEgo  uses  prestored  skeletal  plans  that  efficiently  encode  knowledge 
about  planning  for  dialog.  However,  unlike  those  planners,  UCEgo  selects  for  considera¬ 
tion  only  those  skeletal  plans  that  are  appropriate  to  the  current  situation.  A  plan  is 
judged  appropriate  if  the  goal  of  the  plan  is  currently  a  goal  of  the  system,  and  also  if  the 
preconditions  and  appropriateness  conditions  for  the  plan  are  satisfied  by  being  true  in 
the  current  situation.  UCEgo  indexes  plans  according  to  the  type  of  situation  in  which 
the  plans  are  useful.  As  a  result,  UCEgo  does  not  waste  resources  in  considering  pre¬ 
stored  plans  that  are  inappropriate  and  hence  will  fail. 

Another  difference  between  UCEgo  and  other  planners  is  that  UCEgo  uses  the  idea 
of  meta-planning  developed  by  [Wilensky,  1983]  and  first  implemented  in  part  by 
[Faletti,  1982].  Through  meta-planning,  UCEgo  is  able  to  handle  positive  and  negative 
interactions  among  UCEgo’ s  goals  and  plans.  This  notion  of  meta-planning  is  different 
from  that  of  [Stefik,  1981],  who  used  “meta-planning”  in  reference  to  his  MOLGEN 
planner.  Our  notion  of  meta-planning  involves  the  recursive  application  of  a  planner  to 
solve  its  own  planning  problems  (problems  such  as  interactions  among  goals  or  plans). 
On  the  other  hand,  [Stefik,  1981]  used  “meta-planning”  to  refer  to  a  multi-layered  con¬ 
trol  structure  that  allows  a  planner  to  schedule  its  own  planning  tasks  using  a  variety  of 
strategies,  such  as  least-commitment  or  application  of  heuristics.  WTien  planning  prob¬ 
lems  arose,  MOLGEN  could  only  backtrack.  It  could  not  apply  itself  recursively  to 
create  and  execute  plans  for  handling  the  planning  problems. 

The  rest  of  this  chapter  describes  the  processes  of  planning  and  plan  execution  in 
UCEgo.  Section  2  describes  plan  selection  in  UCEgo,  giving  details  on  the  types  of 
situations  in  which  different  types  of  plans  are  suggested.  Plan  execution  and  other  types 
of  simple  reasoning  in  UCEgo  are  described  in  Section  3. 


2.  Plan  Selection 

UCEgo  selects  plans  based  on  the  current  situation.  Every  plan  in  UCEgo  has  one 
or  more  associated  situation  class .  When  the  situation  class  associated  with  a  plan 
matches  the  current  situation,  that  plan  is  suggested  to  UCEgo.  The  suggestion  of  plans 
based  on  situations  is  implemented  using  if-detected  daemons  (see  Chapter  VI).  If- 
detected  daemons  can  be  considered  tiny  inference  engines  that  look  for  particular 
classes  of  situations.  When  the  current  situation  matches  the  situation  class  of  a  daemon, 
it  performs  appropriate  actions  such  as  suggesting  a  plan. 

A  simple  example  of  an  if-detected  daemon  used  to  suggest  plans  is  shown  in  Fig¬ 
ure  4.1.  This  daemon  suggests  the  plan  (PLANFORl)  of  having  UC  exit  (UC-exitl) 
whenever  UC  has  the  goal  (UC-HAS-GOALl)  of  exiting. 
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Figure  4. 1 .  Suggest  plan  of  executing  the  UC-exit  procedure  when  UC  wants  to  exit. 
2.1.  Situation  Types 

Situations  that  suggest  plans  consist  of  many  different  types  of  information.  A  plan 
situation  always  includes  the  main  goal  of  the  plan.  It  may  also  include  preconditions 
and  other  appropriateness  conditions.  For  example,  the  plan  suggestion  situation  for  a 
USE-CHAIN-SAW  plan  might  include  the  following  appropriateness  condition:  need  to 
cut  thick  branch  (over  1  inch  diameter).  This  appropriateness  condition  is  not  a  precon- 
V  dition,  since  chain  saws  can  be  used  to  cut  smaller  branches.  Indeed,  when  a  user  has 

already  started  using  a  chain  saw  to  cut  some  thick  branches,  the  user  will  often  use  the 
chain  saw  for  smaller  branches.  However,  if  one  had  only  small  branches  to  trim,  one 
would  not  think  of  using  a  chain  saw  (hedge  shears  are  more  appropriate).  Adding  such 
appropriateness  conditions  to  a  plan  suggestion  situation  prevents  the  suggestion  of  inap- 
^  propriate  plans. 

The  plan  suggestion  situations  in  UC  can  be  divided  into  four  main  categories. 
These  are  situation  classes  that  suggest: 

1)  inform-plans 
^  2)  request-plans 

3)  social-plans 

4)  meta-plans 

^  Situations  that  suggest  inform-plans  comprise  those  situations  in  which  the  planner 

wishes  to  inform  the  user  of  some  information.  Request-planning  situations  are  those  in 
which  the  planner  wishes  to  request  information  from  the  user.  Situations  that  invoke 
social-plans  include  salutations  and  apologies.  Meta-planning  situations  involve  suggest¬ 
ing  meta-plans  for  dealing  with  meta-goals.  Each  of  these  situation  classes  and  the  plans 
C  that  are  suggested  to  deal  with  those  classes  of  situation  are  described  in  the  following 

sections. 


f 
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2.2.  Inform-Plans 

UCEgo  suggests  inform-plans  whenever  UC  has  the  goal  of  having  the  usct  know 
something.  There  are  two  situation  classes  in  which  inform-plans  are  detected.  The  two 
classes  are  distinguished  by  the  type  of  information  that  UC  wants  the  user  to  know.  If 
the  knowledge  is  a  network  of  real  concepts,  then  UCEgo  simply  suggests  the  plan  o 
communicating  those  concepts  to  the  user.  On  the  other  hand,  if  UC  wants  the  user  to 
know  something  that  is  only  a  description  of  some  concept(s),  then  UC  should  cominuni- 
cate  to  the  user  the  concept(s)  that  is  the  referent  of  the  descnption.  For  example,  if  UC 
wants  the  user  to  know  “how  to  delete  files,”  then  UC  should  inform  the  user  that  the 
rm  command  is  used  to  delete  files.”  “How  to  delete  files”  is  a  descnption  of  the  con¬ 
cepts  “the  rm  command  is  used  to  delete  files.”  If  UC  were  to  communicate  just  the 
description  to  the  user,  that  would  not  achieve  UC’s  goal  of  having  the  user  know  how  to 
delete  a  file.  UC  needs  to  communicate  the  referent  of  the  description  to  the  user.  As  a 
result,  UC  needs  to  compute  the  referent  before  informing  the  user  in  simations  where 
the  type  of  information  is  a  description. 

The  two  situation  classes  that  suggest  inform-plans  are  summarized  in  Table  4.1. 
The  first  -art  of  the  situation  m  both  situation  classes  is  the  planner’s  goal  of  having  the 
useVknow  something.  The  second  part  of  the  situation  in  the  first  class  represents  the 
precondition  that  the  information  should  not  be  a  description.  The  opposite  is  the  case  in 
the  second  class.  Also,  the  second  class  of  situation  has  the  additional  precondition  that 
the  description  must  have  an  identified  referent. 


Situation 

Suggested  Plan 

Planner  wants  the  user  to  know  ?x, 
and  ?x  is  not  a  description 

tell  the  user  ?x 

Planner  wants  the  user  to  know  ?x, 
and  ?x  is  a  description 
and  ?y  is  the  referent  of  ?x 

tell  the  user  ?y 

Table  4.1.  Situations  that  suggest  inform-plans. 


The  actual  if-detected  daemons  that  detect  inform-plan  situations  and  suggest  the 
plans  are  shown  in  Figures  4.2  and  4.3.  Figure  4.2  shows  the  if-detected  daemon  for 
Ltecting  situations  in  which  UC  has  the  goal  (UC-HAS-GOAL3)  of  having  ^e  user 
know  (KNOWl)  something  (SOMETHINGl)  that  is  not  a  descnption.  Since  descnp- 
tions  in  UC  are  always  hypothetical  (see  Appendix  A,  Secuon  2),  they  can  ^  detect^  by 
checking  to  make  sure  that  the  concept  to  be  communicated  noth^thetical.  Since 
hypothetical  concepts  are  marked  as  being  dominated  by  HYPOTHETICAL  this  mems 
that  the  if-detected  daemon  should  check  to  make  sure  that  whatever  i^^tches  SOME¬ 
THINGl  is  not  dominated  by  HYPOTHETICAL.  This  check  is  indicated  by  the  NOT 
link  from  DOMINATE  1  in  Figure  4.2. 
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Figure  4.2.  Suggest  plan  of  telling  user  when  UC  wants  the  user  to  know  a  real  concept. 

In  the  second  class  of  situations,  UC  wants  the  user  to  know  a  description  for  which 
UC  has  identified  a  referent.  Figure  4.3  shows  the  if-detected  daemon  for  detecting  situa¬ 
tions  in  which  UC  has  the  goal  (UC-HAS-GOAL2)  of  having  the  user  know  (KNOWl) 
something  (SOMETHING  1)  that  is  a  description.  The  referent  of  the  description  is  indi¬ 
cated  by  the  ANSWER-FOR  relation  between  SOMETHING  1  (the  description)  and 
SOMETHING2  (the  referent).  There  is  no  explicit  check  to  make  sure  that  SOME¬ 
THING!  is  indeed  a  description,  because  only  descriptions  participate  in  the  ANSWER- 
FOR  relation. 
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Figure  4.3.  Suggest  plan  of  telling  the  user  the  referent  of  a  description. 

2.3.  Request-Plans 

The  request-plan  is  suggested  by  UCEgo  whenever  UC  wants  to  know  something, 
?x,  and  additionally,  UC  believes  that  the  user  is  likely  to  know  ?x.  The  latter  condition 
is  not  a  precondition  in  the  classical  sense,  since  UC  can  still  use  the  plan  of  asking  the 
user  even  when  UC  does  not  believe  that  it  is  likely  to  work.  Also,  the  fact  that  UC  does 
not  believe  that  the  user  knows  the  information  does  not  mean  that  the  plan  will  neces¬ 
sarily  fail,  since  UC  may  be  mistaken  in  its  beliefs  about  what  the  user  knows.  In  fact, 
when  they  have  no  better  alternatives  (or  are  just  too  lazy  to  try  other  alternatives),  peo¬ 
ple  will  often  ask  someone  else  for  information  even  when  they  believe  that  it  is  very 
unlikely  that  person  knows  the  information.  Thus  the  condition  that  one  only  asks  some¬ 
one  one  believes  knows  the  information  should  not  preclude  use  of  this  plan.  This  con¬ 
tradicts  [Schank  and  Abelson,  1977] ’s  approach  in  which  this  is  termed  an  uncontrollable 
precondition,  meaning  that  this  plan  is  always  aborted,  unless  this  precondition  is  true. 
Nevertheless,  one  does  not  normally  ask  someone  for  information,  when  one  does  not 
believe  that  this  person  possesses  the  information.  This  is  an  example  of  an  appropriate¬ 
ness  condition  for  the  use  of  a  plan.  UCEgo  will  not  suggest  the  plan  of  asking  someone 
for  information  unless  UC  believes  that  the  person  knows  the  information  sought  by  UC. 

Whether  or  not  the  user  knows  the  information  sought  by  UC  is  modeled  by 
KNOME  (see  Chapter  II).  Since  such  information  is  often  not  represented  explicitly  in 
UC’s  knowledge  base,  but  instead  is  inferable  from  the  user’s  level  of  expertise,  a  call  to 
KNOME  is  needed  to  determine  whether  or  not  the  user  knows  something.  Hence  in  the 


if-detected  daemon  for  suggesting  the  request-plan,  the  appropriateness  condition  is 
coded  as  a  test  involving  a  call  to  the  KNOME  procedure,  does-user-know?.  This  is 
shown  in  Figure  4.4. 


Figure  4.4.  Suggest  the  plan  of  asking,  when  it  is  likely  that  the  user  knows. 

2.4.  Social-Plans 

Social-plans  consist  of  salutations  and  apologies.  Common  to  all  situation  classes 
that  suggest  social-plans  is  the  planner’s  goal  of  being  polite  to  the  user.  If  the  planner 
did  not  wish  to  be  polite,  then  there  would  be  no  point  to  either  greeting  the  user  or  apo¬ 
logizing  to  the  user. 

Salutations  include  greetings  and  farewells.  UCEgo  suggests  the  greeting  plan, 
whenever  UC  first  encounters  someone  (a  precondition),  and  UC  has  the  goal  of  being 
polite  to  this  person.  The  plan  of  saying  good-bye  is  suggested,  whenever  UC  has  the 
goal  of  being  polite  and  also  has  the  goal  of  exiting.  Although  there  are  two  UC-goals  in 
the  good-bye  plan’s  suggestion  situation,  only  one  goal  is  satisfied  by  the  good-bye  plan. 
The  good-bye  plan  is  only  a  plan  for  being  polite,  since  UC  cannot  exit  merely  by  means 
of  saying  good-bye  to  the  user.  The  goal  of  exiting  serves  as  an  appropriateness  condi¬ 
tion  for  suggesting  the  plan  of  exiting.  It  is  not  a  precondition,  because  the  planner  can¬ 
not  plan  to  achieve  the  precondition  before  using  this  plan.  It  is  not  even  an  uncontroll¬ 
able  precondition,  since  it  is  a  condition  under  the  planner’s  control.  After  all,  if  a 
planner  has  the  goal  of  being  polite  to  the  user,  then  it  might  try  to  use  the  good-bye  plan, 
and  then  decide  to  exit  in  order  to  satisfy  this  precondition  of  the  good-bye  plan. 

The  if-detected  daemon  that  suggests  the  plan  of  greeting  the  user  is  shown  in  Fig¬ 
ure  4.5.  This  daemon  is  triggered,  whenever  UC  has  the  goal  of  being  polite  to  someone, 
and  UC  encounters  this  person  for  the  first  time.  The  daemon  that  suggests  the  plan  of 
saying  good-bye  to  the  user  is  shown  in  Figure  4.6.  The  situations  that  trigger  this  dae¬ 
mon  are  those  in  which  UC  has  the  goal  of  being  polite  to  someone  and  also  has  the  goal 
of  exiting. 
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Figure  4.5.  Suggest  plan  of  greeting  the  user  when  encountering  a  new  user. 


Figure  4.6.  Suggest  plan  of  saying  good-bye  to  the  user  when  exiting. 

Social  goals  involving  apologies  are  suggested  when  UC  cannot  fulfill  its  obliga¬ 
tions  as  a  consultant.  This  occurs  either  when  UC  cannot  tell  the  user  the  solution  to  the 
user’s  problem  because  UC  does  not  know  the  answer  to  the  user’s  query,  or  when  UC 
does  not  want  to  tell  the  user  the  answer.  In  the  first  case,  UC  apologizes  to  the  user  for 
not  knowing.  In  the  second  case,  UC  apologizes  to  the  user  for  not  being  able  to  tell  the 
user  (this  is  really  a  canned  figure  of  speech,  since  UC  actually  is  able  to  tell  the  user  but 
just  does  not  want  to  do  so).  The  situations  that  suggest  these  plan  of  apology  are  sum¬ 
marized  in  Table  4.2. 
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Situation 

Suggested  Plan 

Planner  has  goal  of  being  polite  to  user. 

User  has  goal  of  knowing  something,  ?x. 

Planner  does  not  know  ?x 

apologize  to  user 
for  not  knowing  ?x 

Planner  has  goal  of  being  polite  to  user. 

User  asked  UC  a  question  about  something,  ?x. 
Planner  wants  to  prevent  the  user  knowing  ?x 

apologize  to  user  for  not 
being  able  to  tell  user  ?x 

Table  4.2.  Situations  that  suggest  plans  of  apology. 


The  actual  if-detected  daemons  that  detect  situations  calling  for  UC  to  apologize  to 
the  user  are  shown  in  Figures  4.7  and  4.8.  In  the  first  daemon,  the  fact  that  UC  does  not 
know  something  has  two  possible  sources.  First,  this  fact  may  already  be  in  UC  s 
knowledge  base.  Secondly,  UCEgo  may  add  such  knowledge  to  UC’s  knowledge  base 
after  one  of  UC’s  other  components  (e.  g.  UC’s  domain  planner)  has  tried  to  solve  the 
user’s  problem  and  reports  a  failure.  For  the  second  daemon,  the  fact  that  UC  wants  to 
prevent  the  user  from  knowing  something  is  usually  the  result  of  a  preservation  goal.  For 
example,  when  the  user  asks  UC  how  to  delete  UC,  this  will  trigger  the  goal  of  preserv¬ 
ing  the  UC  program  and  hence  the  goal  of  preventing  the  user  from  knowing  how  to 
delete  UC.  This  leads  to  a  goal  conflict  for  UC  between  wanting  to  tell  the  user  in  order 
to  help  the  user,  and  wanting  to  prevent  the  user  from  knowing.  In  this  case,  UCEgo 
resolves  the  conflict  by  abandoning  the  goal  of  wanting  to  tell  the  user.  Detecting  such 
goal  conflict  situations  are  described  in  Chapter  HI,  Section  3,  and  the  plan  for  resolving 
the  conflict  is  described  in  this  chapter  in  Section  3.3. 
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Figure  4.7.  Suggest  plan  of  apologizing  when  UC  does  not  know  the  answer. 


Figure  4.8.  Suggest  plan  of  apologizing  when  UC  does  not  want  the  user  to  know. 


-  123- 


V 


tk. 


V 


%■ 


V 


2,5.  Meta-Plans 

Meta-plans  are  just  like  any  other  plans  in  UC.  The  only  difference  is  that  meta¬ 
plans  tend  to  be  useful  for  achieving  meta-goals.  An  example  of  a  meta-plan  is  the  plan 
of  calling  the  procedure,  UC-merge-goals,  in  order  to  satisfy  the  meta-goal  of  MERGE- 
REDUNDANT-GOALS.  The  if-detected  daemon  that  suggests  this  plan  is  shown  in  Fig¬ 
ure  4.9. 


Figure  4.9.  Suggest  plan  of  merging  redundant  goals. 

The  UC-merge-goals  procedure  takes  two  similar  goals  and  merges  them.  UC- 
merge-goals  first  matches  the  two  goals  to  see  if  they  are  identical.  If  so,  the  goals  can  be 
merged  by  simply  discarding  any  one  of  the  goals.  A  more  complex  case  is  when  one  of 
the  goals  is  contained  by  the  other  goal.  In  such  a  case,  UC-merge-goals  discards  the 
contained  goal.  For  example,  if  the  user  asks,  “Is  compact  used  to  compact  files?”  then 
UC  adopts  the  following  three  similar  goals  (see  Chapter  III,  Section  3.2): 

1)  UC  wants  the  user  know  whether  compact  is  used  to  compact  files 

— >  UC  wants  the  user  to  know  that  yes,  compact  is  used  to  compact 

files. 

2)  UC  wants  the  user  to  know  the  effects  of  the  compact  command 

->  UC  wants  the  user  to  know  that  compact  is  used  to  compact  files. 

3)  UC  wants  the  user  to  know  how  to  compact  files 

— >  UC  wants  the  user  to  know  that  to  compact  a  file,  use  compact . 

The  similarity  among  the  goals  does  not  become  apparent  until  after  UC  deduces 
the  referent  of  the  descriptions  in  the  original  goals  (see  Chapter  III,  Section  3.2  for  more 
details  on  detecting  goal  overlap).  Although  theoretically  the  order  of  merging  goals 
does  not  make  any  difference  in  the  final  result,  in  actual  practice  the  referents  of  the 


w 
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descriptions  of  the  first  two  goals  are  found  before  the  third,  so  the  first  two  goals  listed 
above  are  the  first  to  be  merged.  In  merging  the  first  two  goals,  the  second  goal  is  con¬ 
tained  by  the  first,  so  the  goals  are  merged  by  simply  abandoning  the  second  goal.  Next, 
after  UC  identifies  the  referent  of  the  third  goal,  UCEgo  notices  that  it  is  similar  to  the 
first  goal  (a  similarity  with  the  second  goal  is  not  detected,  since  the  second  goal  has 
already  been  abandoned  at  this  point).  Once  again,  the  third  goal  is  approximately  con¬ 
tained  by  the  first  goal  (approximate  in  that  “to  compact  a  file,  use  compact”  is 
represented  as  a  PLANFOR  relation,  which  is  similar  to  but  not  identical  to  the  HAS- 
EFFECT  relation  that  is  used  to  represent,  “compact  is  used  to  compact  files),  so  the 
two  goals  are  merged  by  abandoning  the  third  goal.  These  two  merges  leave  only  the 
first  goal,  which  leads  to  UC’s  answer  of  “Yes.”  The  propositional  part  of  this  answer  is 
pruned  by  UCExpress  (see  Chapter  V,  Section  2). 

Another  of  UCEgo’ s  meta-plans  is  suggested  when  UCEgo  detects  a  goal  conflict 
and  adopts  the  meta-goal  of  resolving  the  conflict.  The  appropriate  meta-plan  is  sug¬ 
gested  by  the  if-detected  daemon  shown  in  Figure  4.10.  This  meta-plan  represents  a  call 
to  the  procedure,  UC-resolve-conflict,  which  resolves  the  conflict  by  abandoning  the  less 
important  of  the  two  conflicting  goals.  To  determine  which  goal  is  less  important,  UC- 
resolve-conflict  first  searches  for  a  direct  precedence  relationship  (represented  by  a 
HAS -PRECEDENCE  relation)  between  the  two  goals.  If  such  a  relation  does  not  exist, 
then  UC-resolve-conflict  expands  the  search  to  include  the  causal  parents  of  the  goals. 
The  search  continues  until  the  ultimate  sources  of  the  goals,  which  are  usually  UC 
themes,  are  included  in  the  check  for  relative  precedence  relations.  Since  goal  conflicts 
usually  involve  goals  that  originate  from  different  UC  themes,  and,  because  all  of  UC’s 
themes  have  a  relative  precedence,  UC-resolve-conflict  is  almost  always  able  to  decide 
which  goal  to  abandon  in  order  to  resolve  the  conflict. 


Figure  4. 10.  Suggest  plan  of  resolving  the  conflict. 

An  example  of  resolving  a  goal  conflict  is  shown  in  the  trace  of  a  UC  session  shown 
in  Figure  4.11.  In  this  dialog,  the  user  asks  UC  how  to  crash  the  system,  which  leads  UC 
to  adopt  the  following  two  conflicting  goals: 
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1)  UC  wants  the  user  know  how  to  crash  the  system  (UC-HAS-GOAL66). 

2)  UC  wants  to  prevent  the  user  from  knowing  how  to  crash  the  system 
(UC-HAS-GOAL67). 

The  first  goal  is  a  sub-goal  of  UC’s  goal  of  helping  the  user,  which  in  turn  originates 
from  UC’s  consultant  role  theme.  The  second  goal  is  a  sub-goal  of  UC’s  goal  of  preserv¬ 
ing  the  system,  which  in  turn  originates  from  UC’s  staying  alive  life  theme.  UCEgo 
detects  the  fact  that  these  two  goals  conflict  (see  Chapter  III,  Section  3.3),  since  UC  both 
wants  to  achieve  some  state  and  prevent  the  achievement  of  that  state.  To  resolve  the 
goal  conflict,  UCEgo  calls  the  UC-resolve-conflict  procedure,  which  checks  the  relative 
precedence  of  the  two  conflicting  goals  and  abandons  the  less  important  goal.  The  search 
for  precedence  terminates  at  UC’s  Stay-Alive  life  theme  and  UC’s  Consultant  role 
theme.  Since  UC’s  life  theme  has  greater  precedence  than  UC’s  role  theme,  the  UC- 
resolve-conflict  procedure  resolves  the  conflict  by  abandoning  the  goal  of  having  the  user 
know  how  to  crash  the  system. 

Although  UCEgo  has  abandoned  the  goal  of  having  the  user  know  how  to  crash  the 
system,  UCEgo  still  has  the  goal  of  being  polite  to  the  user.  This  leads  UCEgo  to  the 
plan  of  apologizing  to  the  user  for  UC’s  inability  to  help  the  user.  UCEgo  suggests  this 
plan  in  a  situation  where  someone  asks  UC  a  question,  UC  wants  to  be  polite  to  this  per¬ 
son,  and  UC  want  to  prevent  that  person  from  knowing  the  answer  to  the  query.  Similar 
plans  calling  for  UC  to  apologize  in  order  to  be  polite  are  suggested  when  UC  does  not 
know  the  answer  and  when  UC  cannot  perform  actions  that  the  user  requests.  More 
details  on  these  and  other  social  plans  can  be  found  in  Section  2.4. 


Welcome  to  UC  (Unix  Consultant)  version  3.23 
To  a  pron^st,  please  type  in  your  questions 

about  the  UNIX  file  system  in  English. 

To  leave,  just  type  ' "D'  or  ' (exit) ' . 

Hi. 

How  can  I  help  you? 

#  How  can  I  crash  the  system? 

The  parser  produces: 

(ASKIO  (listenerlO  =  UC) 

(speakerlO  =  *USER*) 

(asked-forlO  = 

(QUESTIONIO  (what-islO  =  (ACTION14?  (actorl4  =  *USER*) ) ) ) ) ) 
(CRASH-ACTIONO?  (del-effectO  =  (CRASH-EFFECTO? 

(crash-objectO  =  UNIX-SYSTEM) ) ) 
(actorO-l  =  *USER*) 

(causeO-0  =  (ACTION14?  &))))) 
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UC’s  parser  understands  the  user’s  input  as  a  question  about  a  way  to  crash  the  UNIX 
system. 


The  goal  analyzer  produces: 

( (HAS -GOAL -gaO 

(planner-gaO  =  *USER*) 

(goal-gaO  =  (KNOW-gaO?  (knower-gaO  =  *USER*) 

(fact-gaO  =  (ACTION14?  &)))))) 

UCEgo:  suggesting  the  plan: 

(PLANFOR71  (goals71  =  (HELPS  (helpeeS  =  *USER*)  (helpers  =  UC) ) ) 
(plan71  =  (SATISFY6  (need6  =  (KNOW-gaO?  &) ) 

(actor6  =  UC) ) ) ) 

based  on  the  situation: 

(UC -HAS -GOAL 6 3  (status63  =  ACTIVE)  (goal63  =  (HELPS  &))) 
(HAS-GOAL-gaO  &) 


Since  UC  wants  to  help  the  user  (UC-HAS-GOAL63),  and  the  user  wants  (HAS-GOAL- 
gaO)  to  know  (KNOW-gaO)  something,  UCEgo  suggests  the  plan  of  satisfying  the  user’s 
goal  of  knowing. 


UCEgo:  suggesting  the  plan: 

(PLANFOR72 

(goals72  =  (PRESERVES  (preservers  =  UC) 

(preservedS  =  UNIX-SYSTEM) ) ) 

(plan72  = 

(SATISFY7  (need7  =  (PREVENTS  (preventers  =  UC) 

(prevent-stateS  =  (KNOW-gaO?  &) ) ) ) 

(actor7  =  UC) ) ) ) 
based  on  the  situation: 

(PLANFOR-gal  (goals-gal  =  (CRASH-EFFECTO?  &)) 

(plan-gal  =  (ACTION14?  &) ) ) 

(HAS-GOAL-gaO  &) 

(UC-HAS-GOAL59  (statusS9  =  ACTIVE)  (goalS9  =  (PRESERVES  &))) 


Since  the  user  wants  to  know  how  to  alter  (crash  is  a  kind  of  altering)  something  that  UC 
wants  (UC-HAS-GOAL59)  to  preserve,  UCEgo  suggests  the  plan  of  preventing  the  user 
from  knowing  how  to  crash  the  system. 


UCEgo:  detected  the  goal: 

(UC-HAS-G0AL66  (goal66  =  (KNOW-gaO?  &)  )  ) 
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t.. 


4. 


from  the  situation: 

(UC-HAS-INTENTIONIO  (intentionlO  =  (SATISFY6  &)) 

(status 10  =  ACTIVE)) 

UCEgo :  detected  the  goal : 

(UC-HAS-GOAL67  (goal67  =  (PREVENTS  &))) 
from  the  situation: 

(UC-HAS-INTENTION9  (intention9  =  (SATISFY7  &))  (status9  =  ACTIVE)) 


UCEgo  adopts  the  sub-goals  of  having  the  user  know  how  to  crash  the  system  (UC- 
HAS-GOAL66)  and  preventing  the  user  from  knowing  (UC-HAS-GOAL67). 


UCEgo:  detected  the  goal: 

(UC-HAS-GOAL68 

(goal68  =  (RESOLVE -GOAri-CONFLICT2 

(conf lict-goal-A2  =  {UC-HAS-GOAL67  &) ) 
(conf lict-goal-B2  =  (UC-HAS-GOAL66  &))))) 
from  the  situation: 

(UC -HAS -GOAL 6 6  &) 

(UC-HAS-GOAL67  &) 


UCEgo  detects  the  meta-goal  of  resolving  the  conflict. 


UCEgo:  suggesting  the  plan: 

(PLANFOR73  (goals73  =  (RESOLVE-GOAL-CONFLICT2  &)) 
(plan73  =  (UC-resolve-conf lictl 

(goal-Al  =  (UC-HAS-GOAL67  &)) 
(goal-Bl  =  (UC-HAS-GOAL66  &))))) 

based  on  the  situation: 


(UC-HAS-GOAL68  &) 


V 


UCEgo  suggests  the  meta-plan  of  calling  the  UC-resolve-conflict  procedure  to  resolve 
the  goal  conflict. 


V 

UCEgo:  suggesting  the  plan: 

(PLANFOR74 

(plan74  =  (APOLOGIZE2 

(speaker2-2  =  UC) 
(listener2-2  =  *USER*) 

U  (apology2  = 

(HAS-ABILITYl  (abilityl  = 
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(TELL6  {speaker6-0  =  UC) 

(listener6-0  =  *USER*) ) ) 
(truth-vall  =  FALSE) 

(doerl  =  UC) ) ) ) ) 

(goals74  =  (BE-POLITE5  (polite-to5  =  *USER*)  (is-polite5  =  UC) ) ) ) 
based  on  the  situation; 

(ASKIO  &) 

(UC-HAS-GOAL61  (statu361  =  ACTIVE)  (goal61  =  (BE-POLITE5  &) ) ) 
(UC-HAS-GOAL67  &) 


Since  UC  has  the  goal  of  preventing  the  user  from  knowing  something  that  the  user  asked 
about,  and  UC  has  the  goal  of  being  polite  to  the  user,  UCEgo  suggests  the  plan  of  apolo¬ 
gizing  to  the  user  for  not  being  able  to  tell  the  user  in  order  to  be  polite. 


UCEgo:  detected  conflicting  goals: 

(UC-HAS-GOAL67 

(goal67  =  (PREVENTS 

(preventers  =  UC) 

(prevent-stateS  = 

(KNOW-gaO?  (knower-gaO  =  *USER*) 

(fact-gaO  =  (ACTION14? 

(actorl4  =  *USER*) ))))))) 

(UC-HAS-GOAL66 

(goal66  =■  (KNOW-gaO? 

(knower-gaO  =  *USER*) 

(fact-gaO  =  (ACTION14?  (actorl4  =  *USER*)))))) 

UCEgo:  goal,  UC-HAS-GOAL67 ,  has  higher  precedence, 

so  resolving  goal  conflict  by  discarding  the  goal,  UC-HAS-GOAL66 

The  planner  is  passed: 

( (CRASH-EFFECTO?  &)) 

The  planner  produces : 
nil 


As  it  turns  out,  UC  does  not  in  fact  know  how  to  crash  the  system  (the  planner  does  not 
return  a  plan  to  achieve  CRASH-EFFECTO).  However,  even  if  UC  did  know  how,  it 
would  not  tell  the  user,  since  it  has  abandoned  that  goal.  Unfortunately,  UC  did  not 
abandon  the  goal  before  it  had  already  decided  to  call  the  UNIX  domain  planner,  other¬ 
wise  UC  might  save  that  step.  In  a  sense,  UC  is  thinking  in  parallel.  On  the  one  hand,  it 
is  continuing  to  plan  for  both  conflicting  goals,  while  at  the  same  time  it  is  planning  how 
to  resolve  the  conflict  between  the  two  goals.  Potentially,  any  one  of  these  processes 
might  finish  first  So,  the  planner  might  return  a  plan  for  crashing  the  system  and  UC 
might  even  adopt  the  plan  of  telling  this  to  the  user,  before  UC  has  resolved  the  goal 


-  129- 


conflict.  However,  since  UCEgo  separates  planning  and  plan  execution  into  two  distinct 
stages,  UCEgo  will  always  abandon  the  goal  (and  its  sub-goals)  before  it  executes  any 
plans  such  as  telling  the  user  how  to  crash  the  system.  Then  UC  will  not  execute  the 
plan,  since  its  goal  has  been  abandoned  by  UC.  This  separation  of  the  planning  and  plan 
execution  phases  ensures  that  such  subtle  timing  effects  among  parallel  lines  of  thought 
will  not  present  a  problem  for  UCEgo. 


The  generator  is  passed: 

(APOLOGIZE2  &) 

I'm  sorry,  I  cannot  tell  you. 

UCEgo:  do  not  know  a  single  planfor  the  foreground  goal: 
(UC -HAS -GOAL 6 7  &) 
so  adding  the  meta-goal: 

(UC-HAS-GOAL69  (goal69  =  (KNOW60?  (knower60  =  UC) 

(facteO  =  ACTION15?) ) ) ) 

(PLANFOR75?  (goals75  =  (PREVENTS  &) )  (plan75  =  ACTION15?) ) 


The  present  version  of  UCEgo  does  not  know  how  to  prevent  the  user  from  knowing,  so 
it  adopts  the  meta-goal  of  finding  out  a  plan  for  preventing  the  user  from  knowing.  A 
more  complex  version  of  UCEgo  that  did  have  plans  for  preventing  the  user  from  know¬ 
ing  (e.  g.  lying  to  the  user,  threatening  the  user,  etc.)  would  not  need  to  adopt  the  meta¬ 
goal  of  finding  out  such  a  plan. 


The  planner  is  passed: 
((PREVENTS  &)) 

The  planner  produces : 
nil 


Figure  4.1 1.  UC  dialog  showing  the  meta-goal  of  resolving  a  goal  conflict. 


3.  Plan  Execution 

After  UCEgo  has  suggested  a  plan  for  satisfying  a  goal,  it  must  decide  whether  or 
not  to  execute  that  plan.  UCEgo  needs  to  decide  to  execute  a  plan,  rather  than  always 
executing  any  suggested  plan,  because  UCEgo  might  have  to  choose  among  several  alter¬ 
native  plans  that  have  been  suggested.^  Also,  UCEgo  may  have  to  change  or  even 


3  Actually,  this  version  of  UCEgo  never  does  suggest  two  different  plans  for  the  same 
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abandon  a  plan  that  interacts  with  another  of  UCEgo’s  active  plans.  In  order  to  find  such 
plan  interactions  and  correct  them  before  it  is  too  late,  UCEgo  separates  planning  and 
plan  execution  into  two  distinct  phases  of  processing. 

The  planning  process,  especially  planning  fairly  simple  plans  such  as  those  in 
UCEgo,  can  be  considered  a  simple  reasoning  process  similar  to  other  simple  reasoning 
proce'sses.  Other  simple  reasoning  processes  include  figuring  out  which  UNIX  command 
to  use  for  a  particular  purpose,  recalling  the  effects  of  a  particular  UNIX  command,  or 
remembering  the  definition  of  a  term.  In  UCEgo,  each  type  of  reasoning  is  initiated  in 
the  appropriate  situation  by  an  if-detected  daemon.  These  are  described  below. 

3.1.  Intentions 


In  UCEgo’s  first  phase  of  processing,  it  detects  goals,  suggests  plans  for  achieving 
its  goals,  and  adopts  the  intention  of  executing  those  plans.  The  intention  of  executing  a 
plan  means  that  UCEgo  has  scheduled  the  plan  for  execution  during  its  second  phase  of 
processing,  plan  execution.  There  is  one  exception  to  this;  when  the  intended  plan  is  a 
sub-goal  (i.  e.  the  plan  is  to  SATISFY  some  state),  then  UCEgo  immediately  adopts  the 
desired  state  as  a  sub-goal  in  order  to  continue  planning.  The  fact  that  UCEgo  has 
adopted  an  intention  does  not  mean  that  it  cannot  abandon  that  intention  later.  For  exam¬ 
ple  UCEgo  may  abandon  an  intention  to  carry  out  a  plan  if  later  UCEgo  decides  to  aban¬ 
don  the  goal  which  that  plan  is  meant  to  achieve. 


UCEgo’s  notion  of  intention  is  similar  to  [Cohen  and  Levesque,  1987a&b]’s  usage 
of  intention  as  a  persistent  (i.  e.  a  commitment  over  time)  goal  to  do  an  action.  As  in 
their  notion  of  relativized  intention,  UCEgo  abandons  an  intention  when  the  motivation 
for  the  intention  no  longer  holds.  However,  unlike  their  definition  of  intention,  UCEgo 
does  not  worry  about  its  own  beliefs  concerning  commitment  of  the  action.  [Cohen  and 
Levesque,  1987a&b]’s  theoretical  treatment  of  intention  needed  to  be  concerned  about 
the  beliefs  of  the  agent  since  they  wanted  to  be  able  to  rule  out  the  possibility  that  an 
agent  might  intend  to  doing  something  accidentally  or  unknowingly.  In  a  real  system, 
such  as  UCEgo,  intentions  are  adopted  as  part  of  the  planning  process,  so  it  would  never 
accidentally  or  unknowingly  adopt  an  intention  to  perform  an  action.  Such  concerns  are 
more  relevant  to  analyzing  the  intentions  of  other  agents. 


Figure  4.12  shows  the  if-detected  daemon  that  adopts  intentions.  Whenever  UC  has 
a  goal  (UC-HAS-GOALl),  there  is  a  plan  for  that  goal  (PLANFORl),  and  that  PLAN- 
FOR  is  real  and  not  hypothetical  (implemented  by  the  NOT  DOMINATEl),  then  this 
daemon  asserts  that  UC  should  adopt  the  intention  of  carrying  out  the  plan. 


goal.  However,  it  is  possible,  so  UCEgo  was  designed  to  handle  such  contingencies. 
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Figure  4.12.  If-detected  daemon  that  adopts  the  intention  of  executing  a  plan. 

Unlike  other  systems  that  need  to  instantiate  the  abstract  plans  that  are  selected  by 
the  system,  in  UCEgo  plans  are  automatically  instantiated  by  the  if-detected  daemons 
that  suggested  the  plans.  This  is  possible,  because  all  information  relevant  to  the  plan, 
especially  information  needed  to  fully  instantiate  a  plan,  are  encoded  as  part  of  the  situa¬ 
tion  class  in  which  UCEgo  suggests  the  plan.  For  example,  consider  what  happens  when 
the  if-detected  daemon  shown  in  Figure  4.13  is  activated.  This  daemon  suggests  the  plan 
of  adopting  the  sub-goal  (SATISFYl)  of  preventing  (PREVENTl)  the  altering 
(ALTER-EFFECTl)  of  something  (SOMETfflNGl)  in  situations  where: 

1)  UC  wants  (UC-HAS-GOALl)  to  preserve  (PRESERVEl)  that  something 
(SOMETHING  1). 

2)  someone  else  (checked  by  the  NOT  DOMINATE  1  with  dominator  UC- 
HAS-GOALl)  wants  (HAS-GOAL2)  to  alter  it. 
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Figure  4. 1 3.  Suggest  plan  of  preventing  the  altering  of  what  UC  wants  preserved. 

If  the  user  tells  UC,  “I  want  to  delete  UC,”  then  this  is  interpreted  as  “the  user  has 
the  goal  of  deleting  the  UC-program.”  Since  UC  has  the  goal  of  preserving  the  UC- 
program,  this  daemon  is  activated.  As  a  result,  it  creates  a  new  instance  of  PLANFOR 
with  goals  being  the  goal  of  preserving  the  UC-program  and  with  plan  being  a  new 
instance  of  SATISFY.  This  in  turn  has  need  being  a  new  instance  of  PREVENT  with 
preventer  being  UC  and  with  prevent-state  being  deleting  the  UC-program.  The  final 
result  is  a  completely  specified  version  of  the  abstract  plan  stored  under  the  if-detected 
daemon.  So,  since  the  plan  suggested  by  the  daemon  is  already  completely  specified, 
UCEgo  does  not  need  to  further  instantiate  the  abstract  plan. 

After  there  are  no  more  goals  to  be  detected,  plans  to  be  suggested,  intentions  to  be 
adopted,  or  inferences  to  be  made  —  that  is,  after  there  are  no  more  if-detected  daemons 
to  activate  —  UCEgo  proceeds  to  its  next  phase,  executing  those  intentions  that  are  still 
active.  Since  UC  can  only  perform  communicative  actions,  UCEgo  only  has  to  worry 
about  producing  output  to  the  user.  It  does  this  simply  by  talcing  the  concepts  that  it 
wants  to  communicate  to  the  user  and  passing  them  to  the  UCExpress  component,  which 
is  described  in  Chapter  V. 

3.2.  Simple  Reasoning 

Besides  planning  for  goals  and  executing  the  plans,  UCEgo  also  performs  other 
types  of  reasoning  in  certain  situations.  For  example,  when  UCEgo  has  the  goal  of  hav¬ 
ing  someone  (usually  UC  or  the  user)  know  a  plan,  it  calls  the  UNIX  domain  planner 
component  of  UC.  The  if-detected  daemon  that  does  this  is  shown  in  Figure  4.14. 
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Figure  4.14.  Daemon  that  calls  the  UNIX  domain  planner  component  of  UC. 

Calling  the  domain  planner  to  compute  a  plan  for  doing  something  in  UNIX  can  be 
viewed  in  two  ways.  One  might  think  of  this  as  part  of  the  plan  for  satisfying  UC’s  goal 
of  having  the  user  know  how  to  do  something  in  UNIX.  In  this  view,  the  plan  would 
consist  of  two  steps;  figuring  out  the  answer,  and  then  informing  the  user  of  this  answer. 
This  is  technically  correct,  but  it  does  not  seem  cognitively  valid  that  a  consultant  has  to 
do  planning  in  order  to  figure  out  the  answer,  especially  for  the  fairly  simple  queries  that 
UC  can  handle.  When  a  human  UNIX  consultant  is  asked,  “How  can  I  delete  a  file?”  it 
does  not  seem  as  if  the  consultant  thinks,  “I  will  figure  out  the  answer  and  then  tell  the 
user.”  Rather,  the  consultant  seems  to  retrieve  the  answer  from  memory  instinctively 
and  then  plans  to  inform  the  user  of  this  answer.  So,  when  a  human  consultant  is  told, 
“Don’t  think  about  how  to  delete  a  file,”  it  is  very  hard  for  the  consultant  to  stop  the 
thought  processes  that  lead  to  recall  of  the  rm  command.  If  humans  had  to  plan  to  figure 
out  this  information,  then  it  should  be  fairly  easy  to  not  execute  the  plan  and  so  not  think 
about  how  to  delete  a  file. 

UCEgo  takes  the  view  that  such  simple  thought  processes  are  unplanned.  That  is, 
UCEgo  does  not  plan  to  think  and  then  think;  rather,  it  always  performs  simple  thought 
processes  in  appropriate  situations.  Since  these  simple  thought  processes  do  not  lead 
directly  to  actions  on  the  part  of  UC,  they  do  not  interfere  with  UCEgo’s  planning  pro¬ 
cess. 

Another  example  of  a  procedure  that  implements  a  simple  thought  process  for  UC  is 
the  recall  of  the  definition  of  a  term.  The  UC-define  procedure  is  called  by  the  if- 
detected  daemon  of  Figure  4.15,  whenever  UC  wants  someone  to  know  the  definition  of 
a  term.  Similarly,  when  UC  wants  someone  to  know  the  effects  of  some  UNIX  com¬ 
mand,  the  if-detected  daemon  of  Figure  4.16  calls  the  UC-find-effects  procedure.  When 
UC  wants  someone  to  know  whether  something  is  a  plan  for  something  else,  UCEgo 
calls  the  UC-is-planfor  procedure  as  shown  in  Figure  4.17.  Finally,  whenever  UC  wants 
someone  to  know  whether  some  state  holds,  UCEgo  calls  the  UC-is-state  procedure 
shown  in  Figure  4.18. 
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Figure  4.15.  Daemon  for  finding  out  the  definition  of  a  term. 


Figure  4. 16.  Daemon  for  finding  out  the  effects  of  a  command. 


Figure  4.17.  Daemon  for  finding  out  whether  some  action  is  the  plan  for  some  goal. 
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Figure  4. 18.  Daemon  for  finding  out  whether  some  state  holds. 


4.  Conclusion 


4.1.  Summary 

The  main  issue  addressed  by  UCEgo’s  planner  is  efficient  planning.  As  the  main 
dialog  planner  for  the  interactive  UC  system,  UCEgo  needs  to  plan  efficiendy  in  order  to 
be  able  to  respond  to  the  user  in  real  time.  This  is  in  direct  contrast  to  most  other  AI 
planners,  which  did  not  have  this  constraint  and  so  could  afford  to  plan  inefficiendy.  I 
approached  this  problem  of  efficient  planning  in  two  ways.  First,  UCEgo  incorporates  a 
very  simple  planner  that  takes  advantage  of  knowledge  about  typical  speech  acts  encoded 
in  prestored  skeletal  plans  to  completely  avoid  inefficient  weak  methods.  Secondly, 
UCEgo  avoids  inefficient  backtracking  by  selecting  plans  according  to  the  situation. 

UCEgo  encodes  knowledge  about  which  plans  are  typically  useful  in  different  types 
of  situations  by  adding  appropriateness  conditions  to  plans.  These  appropriateness  con¬ 
ditions  are  not  preconditions,  because  plans  can  be  used  even  when  their  appropriateness 
conditions  are  violated  (sometimes  even  successfully).  Appropriateness  conditions 
encode  when  it  is  appropriate  to  use  a  plan,  in  contrast  to  preconditions,  which  encode 
when  it  is  possible  to  use  a  plan.  By  encoding  the  appropriateness  conditions  along  with 
the  preconditions  and  the  goal  of  a  plan  into  a  situation  class,  UCEgo  can  suggest  the 
plan  whenever  it  encounters  a  situation  that  fits  the  situation  class.  These  situation 
classes  are  represented  using  if-detected  daemons,  which  suggest  the  plan  associated  with 
the  situation  class  whenever  the  daemon  detects  a  matching  situation.  By  selecting 
among  only  appropriate  plans  as  opposed  to  all  possible  plans,  UCEgo  avoids  inefficient 
backtracking  during  planning. 

UCEgo’s  success  shows  that  a  very  simple  planner  that  is  based  on  prestored  skele¬ 
tal  plans  and  that  does  not  backtrack  can  be  used  successfully  to  plan  speech  acts. 
UCEgo  also  shows  that  it  is  possible  to  plan  speech  acts  without  having  to  worry  about 
mutual  beliefs  to  the  extent  that  the  OSCAR  system  ([Cohen,  1978])  did.  For  example. 
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to  produce  a  simple  inform  type  speech  act,  UCEgo  worries  only  about  having  the  user 
believe  the  proposition,  whereas  OSCAR  worried  about  having  the  user  believe  that  the 
system  believes  the  proposition,  and  then  this  belief  convincing  the  user  to  believe  the 
proposition.  In  everyday  usage,  when  the  system  does  not  have  any  a  priori  reason  to 
believe  that  the  user  might  disagree  with  the  system  (such  as  during  argumentation),  such 
complex  reasoning  about  mutual  beliefs  is  not  absolutely  necessary  for  planning  speech 
acts.  Even  when  the  system  fails  to  convince  the  user  by  simply  informing  the  user  of 
the  proposition,  it  can  still  notice  the  user’s  incredulity  and  correct  the  situation  by  pro¬ 
viding  additional  support  for  the  proposition. 

4.2.  Problems 

One  potential  shortcoming  of  planning  as  implemented  in  UCEgo  is  that  UCEgo 
does  not  have  the  capability  to  fall  back  on  weak  methods  when  it  fails  to  find  a  prestored 
plan.  In  one  sense,  this  shows  that  UCEgo’s  approach  is  superior  since  UCEgo  never 
needs  to  fall  back  on  inefficient  weak  methods  to  plan  speech  acts.  This  agrees  with 
people’s  intuitions  that  they  are  not  planning  from  scratch  in  everyday  conversation.  On 
the  other  hand,  people  do  fall  back  on  plannmg  from  scratch  occasionally  (more  fre¬ 
quently  when  writing  than  when  speaking).  So,  to  be  complete,  UCEgo  should  have  such 
a  capability. 

Unlike  skeletal  plans  ([Friedland,  1980]  and  [Friedland  and  Iwasaki,  1985]),  the 
UCEgo’s  plans  are  not  organized  into  a  abstraction  hierarchy,  but  are  encoded  at  a  single 
level  of  abstraction.  For  planning  speech  acts,  this  is  not  a  real  problem,  because 
UCEgo’s  single  level  of  plan  abstraction  matches  the  single  level  of  communication 
abstraction  that  is  represented  by  speech  acts.  The  lower  levels  of  communication 
abstraction,  choice  of  expressions  and  words,  are  handled  by  UC  s  expression  mechan¬ 
ism  (UCExpress,  see  chapter  V)  and  tactical  generator.  The  higher  levels  of  abstraction 
(i.  e.  paragraphs  and  larger  units)  are  not  addressed  by  UCEgo.  If  UCEgo  were  to  be 
extended  to  handle  real  world  actions  besides  speech  acts,  or  if  UCEgo  were  to  be 
extended  to  plan  larger  communicative  units  than  speech  acts,  then  UCEgo  would  need 
to  organize  plans  into  an  abstraction  hierarchy. 

In  order  to  organize  plans  into  an  abstraction  hierarchy,  one  should  also  organize 
the  situations  that  suggest  plans  into  a  abstraction  hierarchy  of  situation  classes. 
Currently,  UCEgo  does  not  organize  situation  classes  into  an  abstraction  hierarchy, 
although  such  a  hierarchy  would  also  be  useful  for  other  tasks  such  as  detecting  goals. 
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Chapter  V 

Answer  Expression 


After  UCEgo  produces  a  plan  consisting  of  communicative  acts,  the  plan  is  further 
refined.  Refinement  of  communicative  acts  is  needed  because  the  concepts  that  UC 
wants  to  communicate  to  the  user  are  often  not  organized  in  easily  understood  formats 
and  often  complete  to  the  point  of  verbosity.  The  process  of  refining  communicative 
actions  is  called  answer  expression  ([Luria,  1982]).  The  subcomponent  of  UCEgo  that 
does  answer  expression  is  called  UC  Express .  This  chapter  describes  how  UCExpress 
refines  a  communicative  plan  to  produce  a  clear,  concise  answer  for  expression  to  the 
user. 


1.  Introduction 


To  see  why  answer  expression  is  necessary,  consider  the  following  example: 


User:  What  is  a  directory? 

Al:  A  directory  is  a  file. 

A2:  A  directory  is  a  file  that  is  used  to  contain  files. 

A3:  A  directory  is  a  file.  Only  empty  directories  can  be  deleted.  Direc¬ 

tories  cannot  be  edited.  Directories  contain  files.  Directories  form  a 
tree-like  structure.  Directories  always  contain  themselves  and  their 
parents.  A  plan  for  listing  a  directory  is  to  use  the  Is  command. 

The  different  replies  are  all  correct,  but  contain  differing  amounts  of  information.  The 
first  answer  does  not  give  enough  information  to  distinguish  between  files  and  direc¬ 
tories.  The  second  answer  (what  UC  actually  produces)  provides  just  enough  informa¬ 
tion  in  a  concise  form  and  is  the  best  answer  in  this  situation.  The  third  answer  is  too 
verbose  and  overwhelms  the  user  with  information.  An  answer  like  A3  would  be  more 
appropriate  in  cases  where  the  user  had  requested,  “Tell  me  all  you  know  about  direc¬ 
tories.” 

This  example  illustrates  the  problem  of  determining  how  much  of  the  answer  to 
express  to  the  user.  Such  considerations  are  similar  to  Luria’ s  work  ([Luria,  1982])  on 
answering  “why”  questions  in  a  story  understanding  system.  He  pointed  out  that  to 
answer  “why”  questions  required  two  mechanisms,  one  to  find  the  causal  chain  that 
represents  the  answer,  and  another  answer  expression  mechanism  to  determine  how 
much  of  the  causal  chain  to  tell  the  user. 

Another  problem  in  answer  expression  is  deciding  what  format  to  use  to  present  the 
answer.  Consider  the  following  scenario: 
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User:  How  can  I  move  a  file  to  another  machine? 

Al:  To  move  a  file  to  another  machine,  type  ‘rep’  followed  by  one  or  more 

spaces  or  tabs  followed  by  the  name  of  the  file  to  be  moved  followed 
by  one  or  more  spaces  or  tabs  followed  by  the  name  of  the  machine  fol¬ 
lowed  by  a  colon  followed  by  the  new  name  of  the  file  on  the  other 
machine  followed  by  a  carriage  return  followed  by  ‘rm’  followed  by 
one  or  more  spaces  or  tabs  followed  by  the  name  of  the  file. 

A2:  Use  rep  to  copy  the  file  to  another  machine  and  then  use  rm  to  delete  it. 

For  example,  to  move  the  file  foo  to  the  file  fool  on  machine  dali,  type 
‘rep  foo  dali:fool’. 

The  first  answer  is  correct  and  quite  general,  but  it  is  so  verbose  that  it  is  undecipherable. 
On  the  other  hand,  the  second  answer  is  succinct  and  gives  the  user  information  in  an 
easily  readable  form,  but  it  is  considerably  less  general.  In  fact  the  second  answer  is 
somewhat  inaccurate,  since  it  applies  only  to  copying  a  file  named  foo  to  a  file  named 
fool.  It  is  up  to  the  reader  to  use  analogous  reasoning  to  apply  this  to  other  cases. 
Despite  this  lack  of  generality,  the  second  answer  form  is  clearly  superior  to  the  first. 
Note  that  for  a  program  to  format  the  answer  in  the  second  form  requires  additional  com¬ 
putation  to  transform  the  general  solution  of  Al  into  an  example.  A  natural  language  sys¬ 
tem  needs  to  incorporate  knowledge  about  when  and  how  to  use  special  presentation  for¬ 
mats  like  examples  to  more  clearly  convey  information  to  the  user. 

These  concerns  about  how  much  information  to  present  to  the  user  and  about  what 
format  to  use  can  be  viewed  as  corresponding  respectively  to  Grice’s  Maxims  of  Quan¬ 
tity  and  Quality  ([Grice,  1975]).  Although  such  considerations  can  be  considered  part  of 
generation,  there  are  sufficient  differences  in  both  the  necessary  knowledge  and  the  pro¬ 
cessing  to  separate  such  strategic  concerns  from  the  more  tactical  problems  of  generation 
such  as  agreement  and  word  selection.  These  strategic  problems  are  the  domain  of  an 
expression  mechanism. 

UCExpress,  operates  in  two  phases,  pruning  and  formatting .  During  pruning, 
UCExpress  prunes  common  knowledge  from  the  answer  using  information  about  what 
the  user  knows  based  on  the  conversational  context  and  a  model  of  the  user  s  knowledge. 
Next  the  answer  is  formatted  using  specialized  expository  formats  for  clarity  and  brevity. 
The  result  is  converted  to  natural  language  using  a  tactical  level  generator. 


2.  Pruning 

When  UCExpress  is  passed  a  set  of  concepts  to  communicate  to  the  user,  the  first 
stage  of  processing  prunes  them  by  marking  any  extraneous  concepts,  so  that  later  the 
generator  will  not  generate  them.  The  pruning  is  done  by  marking  rather  than  actual 
modification  of  the  conceptual  network,  since  information  about  the  node  may  be  needed 
to  generate  appropriate  anaphora  for  the  pruned  concept. 

The  guiding  principle  in  pruning  is  to  not  tell  the  user  anything  that  the  user  already 
knows.  Currently  UC  models  two  classes  of  information  that  the  user  may  already  know. 


-  139- 


The  first  class  of  information  is  episodic  knowledge  from  a  model  of  the  conversational 
context.  The  current  conversational  context  is  tracked  by  marking  those  concepts  that 
have  been  communicated  in  the  current  session.  The  second  class  of  information  con¬ 
cerns  the  user’s  knowledge  of  UNIX  related  facts.  Such  user  knowledge  is  modeled  by 
KNOME  (see  Chapter  H).  Thus  any  concept  that  is  already  present  in  the  conversational 
context  or  that  KNOME  indicates  is  likely  to  be  known  to  the  user  is  marked  and  is  not 
communicated  to  the  user. 

2.1.  An  Example  Trace 

Consider  the  trace  of  a  UC  session  shown  in  Figure  5.1. 


Welcome  to  UC  (Unix  Consultant)  version  3.23 
To  a  '#'  proii¥>t,  please  type  in  your  questions 
about  the  UNIX  file  system  in  English. 

To  leave,  just  type  '  “D'  or  '  (e^cit) '  . 

Hi. 

How  can  I  help  you? 

#  How  can  I  print  a  file  on  the  laser  printer? 

The  parser  produces: 

(ASKIO  (listenerlO  =  UC) 

(speakerlO  =  *USER*) 

(asked-forlO  = 

(QUESTIONIO  (what-islO  =  (ACTION14?  (actorl4  =  *USER*) ) ) ) ) ) 
(PRINT-ACTIONO?  (pr-effecto  =  PRINT-EFFECTO? ) 

(actorO-1  =  *USER*) 

(causeO-0  =  (ACTI0N14?  &) ) ) 

(HAS-PRINT-DESTO  (pr-destO  =  LASER-PRINTERO ) 

(pr-dest-objO  =  PRINT-EFFECTO?)) 

(HAS-PRINT-OBJECTl  (pr-objectl  =  FILES?) 

(pr-obj-objl  =  PRINT-EFFECTO?)) 

The  goal  analyzer  produces: 

( (HAS -GOAL -gaO 

(planner-gaO  =  *USER*) 

(goal-gaO  =  (KNOW-gaO?  (knower-gaO  =  *USER*) 

(fact-gaO  =  (ACTION14?  &)))))) 


The  planner  is  passed: 
(PRINT-EFFECTO?) 

The  planner  produces : 

(PLANFOR260 

(goals260  =  PRINT-EFFECTO?) 
(plan260  =  (UNIX-LPR-Plz -COMMANDO 
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(Ipr-plz-fileO  =  FILES?) 

(UNIX-LPR-Plz-COMMAND-ef fectO  =  PRINT-EFFECTO ? ) ) ) ) 
(HAS -FILE -NAME 18  (named-f ilel8  =  FILES?) 

(file-namel8  =  (lisp=  nil))) 

( LP  R-P 1 z -HAS -FORMAT  0 

(LPR-Plz-HAS-FORMAT-commandO  =  (UNIX-LPR-Plz-COMMANDO  &) ) 
(LPR-Plz-HAS-FORMAT-formatO  = 

(LPR-Plz-FORMATl 
(Ipr-plz-f ile-argl  = 

(f ile-namel8  =  aspectual-of  (HAS-FILE-NAME18  &) ) ) 
(LPR-Plz-FORMAT-stepl  = 

(SEQUENCEIO  (steplO  =  Ipr) 

(nextio  =  (CONCATOO  (concat-stepOO  =  -P) 

(concat-nextOO  =  Iz) ))))))) 

( HAS -COMMAND -NAME S 0 

(HAS-COMMAND-NAME-named-objSO  =  (UNIX-LPR-Plz-COMMANDO  &)) 
(HAS-COMMAND-NAME-naitieSO  =  (SEQUENCEIO  &))) 

Express:  now  expressing  the  PLANFOR: 

(PLANFOR260  &) 

Express:  not  expressing  the  format  of  the  command, 

UNIX-LPR-Plz-COMMANDO,  since  the  user  already  knows  it. 

Express:  not  expressing  PRINT-EFFECTO?, 

since  it  is  already  in  the  context. 

The  generator  is  passed: 

(TELL?  (listener7-0  =  *USER*) 

(speaker7-0  =  UC) 

(proposition?  =  (PLANFOR260  &)) 

(effect?  =  (STATE-CHANGEl 

( f inal-statel  =  (KNOW-gaO?  &))))) 

The  generator  is  passed: 

(TELLS  (speakers  =  UC) 

(listeners  =  *USER*) 

(propositions  =  (REMINDERIO  &) ) ) 

Use  Ipr  -Plz . 

Don' t  forget  to  file  the  printer  output  in  the  boxes . 


Figure  5.1.  UC  session  with  an  intermediate  user  showing  trace  of  UCExpress. 


The  above  example  traces  UCExpress’  processing  of  the  question,  “How  can  I  print 
a  file  on  the  laser  printer?”  The  answer  given  by  UC  is,  “Use  Ipr  -Plz,”  along  with  a 
reminder  to  file  the  printer  output  in  the  boxes  (see  Chapter  HI,  Section  5.3  for  details  on 
reminder  type  suggestions).  The  actual  KODIAK  conceptual  network  that  is  passed  to 
UCExpress,  shown  in  Figure  5.2,  is  not  nearly  as  succinct,  because  it  contains  all  of  the 
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details  of  the  command  that  are  needed  for  planning. 


Figure  5.2.  KODIAK  representation  of  the  Ipr  -Plz  plan  for  printing. 

If  the  KODIAK  network  passed  to  UCExpress  were  to  be  generated  directly  into 
English,  it  might  look  like  the  following: 

To  print  a  file  on  the  laser  printer,  use  the  Ipr  -Plz  command.  The  command- 
format  of  the  Ipr  -Plz  command  is  “Ipr”  followed  by  concatenating  “-P”  with 
“Iz”  followed  by  the  name  of  the  file  to  be  printed  on  the  laser  printer. 

This  literal  paraphrase  is  harder  to  understand  than  UC’s  more  concise  answer.  To  see 
how  UCExpress  prunes  the  network  to  arrive  at  the  actual  answer,  consider  the  division 
of  the  concepts  into  the  following  three  subnetworks: 


PLANFOR260:  A  plan  for  PRINT-EFFECTO  is 

UNIX-LPR-Plz-COMMANDO 

PRINT-EFFECTO:  printing  a  file  on  the  laser  printer 

LPR-Plz-HAS-FORMATO:  the  command-format  of  the  UNIX-LPR-Plz-COMMANDO 

is  “Ipr  -Plz  <the  name  of  the  file  to  be  printed>” 


These  three  subnetworks  are  depicted  in  Figure  5.2  as  regions  enclosed  in  double  lines. 
In  traversing  this  network,  UCExpress  prunes  LAS -PRINT-EFFECTO,  because  “printing 
a  file  on  the  laser  printer”  is  already  a  part  of  the  context  (it  is  part  of  the  user’s  ques¬ 
tion).  Also,  the  command-format  (LPR-Plz-HAS-FORMATO)  is  pruned  from  UC  s 
actual  answer  based  on  information  from  KNOME.  In  this  case,  KNOME  was  able  to 
deduce  that,  since  the  user  was  not  a  novice,  the  user  already  knew  the  UNDC-LPR-Plz- 
FORMAT,  which  is  an  instance  of  the  SIMPLE-FILE-FORMAT  (the  name  of  the  com¬ 
mand  followed  by  the  name  of  the  file  to  be  operated  upon),  which  all  non-novice  users 
know.  Finally  what  is  left  unpruned  is  the  plan  part  of  PLANFOR50,  UNIX-LPR-Plz- 
COMMANDO,  which  the  generator  translates  as  “Use  Ipr  -Plz.” 

If  the  user  was  just  a  novice,  then  UC  could  not  assume  that  the  user  already  knew 
the  command-format  and  instead  would  provide  the  following  answer  that  includes  an 
example  of  the  Ipr  -Plz  command-format: 

Use  Ipr  -Plz. 

For  example,  to  print  the  file  foo  on  the  laser  printer,  type  Tpr  -Plz  foo’. 


3.  Formatting 

After  pruning,  UCExpress  enters  the  formatting  phase,  during  which  it  tries  to  apply 
different  expository  formats  to  express  concepts  in  a  clearer  manner.  Current  expository 
formats  include  example,  definition  and  simile  formats.  Each  expository  format  is  used  to 
express  different  types  of  information.  They  are  triggered  by  encountering  particular 
concept  types  in  the  answer  network.  After  triggering,  the  procedural  component  of  the 
expository  format  is  called  to  transform  the  concept  into  the  corresponding  format.  The 
formats  are  not  simple  templates  that  can  be  filled  in  with  readily  available  information. 
A  fair  amount  of  additional  processing  is  needed  to  transform  the  information  into  the 
right  format. 

3.1.  Example  Format 

The  example  format  is  used  in  expressing  general  knowledge  about  complex  (i.  e. 
multi-step)  procedures  such  as  UNIX  commands.  In  UC’s  representation  of  UNIX  com¬ 
mands,  every  command  has  an  associated  command  format.  When  expressing  a  com¬ 
mand,  UCExpress  checks  to  see  if  it  should  also  express  the  format  of  the  command.  If 


r 


i. 
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KNOME  believes  that  the  user  already  knows  the  format  of  the  command,  then  there  is 
no  need  to  express  the  format.  Next,  UCExpress  checks  to  see  if  the  format  of  the  com¬ 
mand  is  completely  specified.  If  so,  UCExpress  collapses  the  command  and  format  into 
a  single  statement  as  shown  in  the  trace  of  a  UC  dialog  shown  in  Figure  5.3. 


C 


Welcome  to  UC  (Unix  Consultant)  version  3.23 
To  a  proit^t,  please  type  in  your  questions 

about  the  UNIX  file  system  in  English. 

To  leave,  just  type  ' *D'  or  '(exit)'. 

Hi. 

How  can  I  help  you? 

#  How  can  I  add  general  write  protection  to  the  file  personal? 

Type  'chmod  o-w  personal' . 


Figure  5.3.  UC  Session  with  an  answer  that  combines  the  command  and  format. 


^  An  English  rendition  of  the  conceptual  network  passed  to  UCExpress  for  the  above 

example  might  be  something  like: 

A  plan  for  adding  general  read  protection  to  the  file  personal  is  to  use  the 

chmod  command  with  format  ‘chmod’  followed  by  concatenating  ‘o’  with  ‘-’ 

^  with  ‘r’  followed  by  ‘personal’. 

Since  the  command  is  completely  specified,  the  format  of  the  command  is  combined  with 
the  command  to  form  a  single  statement. 

If  the  command  is  not  completely  specified,  then  UCExpress  uses  an  example  for- 
^  mat  to  express  the  format  of  the  command  to  the  user.  The  key  principle  in  producing 

examples  is  to  be  explicit.  So,  UCExpress  first  steps  through  a  copy  of  the  general  pro¬ 
cedure  to  transform  any  general  information  into  specific  instances.  In  cases  where  the 
underspecified  part  of  the  procedure  has  a  limited  range  of  options,  an  arbitrary  member 
that  is  compatible  with  the  rest  of  the  procedure  and  with  previous  UCExpress  choices  is 
^  selected.  Next,  the  new,  completely  specified  copy  of  the  format  is  combined  with  a 

copy  of  the  command,  much  as  in  the  above  UC  dialog.  Finally  the  new  plan  is  encapsu¬ 
lated  in  an  example  shell  (which  tells  the  generator  to  produce  “For  example,’’). 

To  see  the  algorithm  in  more  detail,  consider  the  UC  dialog  shown  in  Figure  5.4. 
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Welcome  to  UC  (Unix  Consultant)  version  3.23 
To  a  prompt,  please  type  in  your  questions 

about  the  UNIX  file  system  in  English. 

To  leave,  just  type  ' 'D'  or  ' (exit) ' . 

Hi. 

How  can  1  help  you? 

#  How  can  I  change  the  read  permission  of  a  file? 

The  parser  produces : 

(ASKIO  (listenerlO  =  UC) 

(speakerlO  =  *USER*) 

(asked-forlO  = 

(QUESTIONIO  (what-islO  =  (ACTION14?  (actorl4  =  *USER*) ) ) ) ) ) 
(CHANGE-PROT-FILE-ACTIONO? 

(ch-prot-effecto  =  (CHANGE-PROT-FILE-EFFECTO? 

(change-protO  =  FILE-PROTECTIONl) 

(change-f ileO  =  FILES?))) 

(actorO-1  =  *USER*) 

(causeO-0  =  (ACTION14?  &))))) 

(HAS-FILE-PROTECTION2  (prot-file2  =  FILES?) 

(file-prot2  =  FILE-PROTECTIONl)) 
(HAS-ACCESS-TYPEl  (access-protection-typel  =  READ-PROT) 

(prot-type-argl  =  FILE-PROTECTIONl)) 

The  goal  analyzer  produces : 

( (HAS-GOAL-gaO 

(planner-gaO  =  *USER*) 

(goal-gaO  =  (KNOW-gaO?  (knower-gaO  =  *USER*) 

(fact-gaO  =  (ACTION14?  &)))))) 


The  planner  is  passed: 

((CHANGE-PROT-FILE-EFFECTO?  &)) 

The  planner  produces ; 

(PLANFORSSO 

(goalsSSO  =  (CHANGE-PROT-FILE-EFFECTO?  &) ) 

(planSSO  = 

(UNIX-CHMOD-COMMANDO  (chmod-fileO  =  FILES?) 

(chmod-protectionO  =  FILE-PROTECTIONl) 
(UNIX-CHMOD-COMMAND-ef fectO  = 
(CHANGE-PROT-FILE-EFFECTO?  &))))) 
(HAS-FILE-NAME19  (named-f ilel 9  =  FILES?) 

(file-namel9  =  (lisp=  nil) ) ) 

( HAS -P ROT -VALUE 1  (prot-type-argl-1  =  FILE-PROTECTIONl) 

(value-protection-typel  =  (lisp=  nil) ) ) 

(HAS -USER-TYPE 1  (prot-type-argl-0  =  FILE-PROTECTIONl) 
(user-protection-typel  =  (lisp=  nil) ) ) 
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C 


( CHMOD -HAS -FORMAT 0 

(CHMOD-HAS-FORMAT-coiranandO  =  (UNIX-CHMOD-COMMANDO  &) ) 
(CHMOD-HAS-FORMAT-formatO  = 

(CHMOD -FORMAT 0 

(CHMOD-FORMAT-stepO  =  chmod) 

(CHMOD -FORMAT- a rgsO  =  .  .  .  )  )  )  ) 

( HAS -COMMAND -NAME 8 0 

(HAS-COMMAND-NAME-named-obj80  =  (UNIX-CHMOD-COMMANDO  &) ) 

(HAS -COMMAND -NAME -name 80  =  chmod)) 

Express:  now  expressing  the  PLANFOR: 

(PLANFOR330  &) 

Express:  creating  an  example  for  the  incomplete  plan,  CHMOD-FORMATO 

Express:  choosing  a  name,  foo,  for  an  example  file. 

Express:  selecting  USER-PROT  —  print  name,  u, 

to  fill  in  a  parameter  of  the  example. 

Express:  selecting  ADD-STATUS  —  print  name,  +, 

to  fill  in  a  parameter  of  the  example. 

Express:  created  the  example (s): 

( (TELL7 

(spea)cer7-0  =  UC) 

(listener7-0  =  *USER*) 

(proposition7  = 

(EXAMPLEO 
( example 0  = 

(PLANFOR330-0 

(goals330-0  =  (CHANGE-PROT-FILE-EFFECTO-0? 

(change-protO— 0  =  FILE— PROTECTIONl-0) 
(change-fileO-0  =  FILE3-0?))) 

(plan330-0  = 

(TYPE-ACTIONO  (speakerO-4  =  *USER*) 

(type-stringO  = 

( CHMOD -FORMAT 0 - 0 
(CHMOD-FORMAT-stepO -0  =  chmod) 
(CHMOD-FORMAT-argsO-0  = 

(CHMOD-TWO-ARG-SEQO-0 
(chmod-f ile-argO-0  =  ...  foo) 
(CHMOD-TWO-ARG-SEQ-StepO-0  = 
(PROT-ARG-SEQO-0 
(user-bitO-0  =  ...  u) 
(PROT-ARG-SEQ-concat-nextO-0  = 
(ARG-SEQO-0 

(value-bitO-0  =  ...  +) 

(access-bitO-0  =  r) ))))))))))))))) ) 

Express:  not  expressing  CHANGE-PROT-FILE-EFFECTO? , 

since  it  is  already  in  the  context. 
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The  generator  is  passed: 

(TELL6  (effecte  =  (STATE-CHANGEl  (f inal-statel  =  (KNOW-gaO?  &) ) ) ) 
(listener6-0  =  *USER*) 

(speaker6-0  =  UC) 

(proposition6  =  (PLANFOR330  &)  )  ) 

The  generator  is  passed: 

(TELL7  &) 

Use  chmod. 

For  example,  to  add  group  read  permission  to  the  file  named  foo, 
type  'chmod  g+r  foo' . 


Figure  5.4.  UC  Session  showing  an  answer  that  contains  an  example. 


The  conceptual  answer  that  is  passed  to  UCExpress  in  the  above  dialog  can  be  para¬ 
phrased  in  English  as; 

A  plan  for  changing  the  read  permission  of  a  file  is  to  use  the  chmod  command 
with  format  ‘chmod’  followed  by  concatenating  <the  protection-user-type> 
with  <the  protection-value-type>  with  ‘r’  followed  by  <the  name  of  the  file  to 
be  changed>. 

In  stepping  through  the  above  format,  <the  protection-user-type>  is  underspecified.  In 
order  to  give  an  example,  a  particular  value  is  needed,  so  UCExpress  arbitrarily  chooses 
a  value  firom  the  list  of  possible  fillers  (user,  group,  other,  or  all).  The  same  is  done  for 
<the  protection- value-type>.  In  the  case  of  ‘r’,  this  is  already  a  fully  specified  value  for 
protection-access-type,  so  UCExpress  maintains  the  selection.  However,  with  <the  name 
of  the  file  to  be  changed>,  there  is  no  list  of  possible  fillers.  Instead,  UCExpress  calls  a 
special  procedure  for  selecting  names.  This  naming  procedure  chooses  names  for  files 
starting  with  ‘foo’  and  continuing  in  each  session  with  ‘fool’,  ‘foo2’,  etc.  Other  types  of 
names  are  selected  in  order  from  lists  of  those  name  types  (e.  g.  machine  names  are 
chosen  from  a  list  of  local  machine  names).  By  selecting  the  names  in  order,  name 
conflicts  (e.  g.  two  different  files  with  the  same  name)  can  be  avoided. 

Another  consideration  in  creating  examples  is  that  new  names  must  be  introduced 
before  their  use.  Thus  ‘foo’  should  be  introduced  as  a  file  before  it  appears  in  ‘chmod 
g+r  foo’.  This  is  done  implicitly  by  passing  the  entire  PLANFOR  as  the  example,  so  that 
the  generator  will  produce  ‘to  add  group  read  permission  to  the  file  named  foo  as  well  as 
the  actual  plan. 

3.2,  Definition  Format 

The  definition  format  is  used  to  express  definitions  of  terminology.  The  UC-define 
procedure  first  collects  the  information  that  will  be  expressed  in  the  definition. 
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Collecting  the  right  amount  of  information  involves  satisfying  the  Gricean  Maxim  of 
Quantity.  The  usual  procedure  is  to  collect  the  information  that  the  term  has  some 
semantic  category,  and  then  add  the  primary  usage  of  the  term.  In  rare  cases  where  the 
node  does  not  have  a  usage,  some  other  property  of  the  node  is  chosen.  For  example,  a 
definition  of  a  directory  would  include  the  information; 

1)  directories  are  files 

2)  directories  are  used  to  contain  files 

After  such  information  is  collected,  it  must  be  transformed  into  a  definition  format. 
This  involves  creating  instances  of  both  the  term  and  its  category  and  then  combining  the 
two  pieces  of  information  into  one  coherent  statement  The  latter  task  requires  an  attach¬ 
ment  inversion  where  the  distinguishing  information  is  reattached  to  the  term  s  category 
rather  than  to  the  term  itself.  For  example,  the  information  about  directory  containing 
files  is  reattached  to  form  “a  file  that  is  used  to  contain  files”  in  the  following  definition; 

User;  What  is  a  directory? 

UC;  A  directory  is  a  file  that  is  used  to  contain  files. 

This  attachment  inversion  is  not  specific  to  English  but  seems  to  be  a  general  universal 
linguistic  phenomenon  in  the  expression  of  definitions.  Here  are  some  other  examples  of 
the  definition  format; 

User;  What  is  a  file? 

UC;  A  file  is  a  container  that  is  used  to  contain  text,  code,  or  files. 

User;  What  is  a  container? 

UC;  A  container  is  an  object  that  is  used  to  contain  objects. 

User;  What  is  rm? 

UC;  Rm  is  a  command  that  is  used  to  delete  files. 

User;  What  is  a  search  path? 

UC;  A  search  path  is  a  list  of  directories  that  is  used  by  the  csh  to  search  for 
programs  to  execute. 


3.3.  Simile  Format 


The  simile  format  is  used  by  UCExpress  to  provide  explanations  of  what  a  com¬ 
mand  does  in  terms  of  other  commands  already  known  to  the  user.  This  format  is 
invoked  when  UCExpress  attempts  to  explain  a  command  that  has  a  sibling  or  a  parent  in 
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the  command  hierarchy  that  the  user  already  knows  (as  modeled  in  KNOME).  An  exam¬ 
ple  is  explaining  what  ruptime  does  in  terms  of  uptime.  A  trace  of  UC  s  processing  is 
shown  in  Figure  5.5 


Welcome  to  UC  (Unix  Consultant)  version  3.23 
To  a  '#'  pronfJt,  please  type  in  your  questions 
about  the  UNIX  file  system  in  English. 

To  leave,  just  type  ' “D'  or  '  (exit) ' . 


Hi. 

How  can  I  help  you? 

#  What  does  ruptime  do? 


The  parser  produces: 

(ASKIO  (listenerlO  =  UC) 

(speakerlO  =  *USER*) 
(asked-fcrlO  =  (QUESTIOMIO 


^.v,a4-_isl0  ^  STATE13?) 


(HAS-EFFECT21?  (ef f ect-of-command21  =  STATE13?) 

(coinmand-of-effect21  =  UNIX-RUPTIME-COMMANDO )  ) 


The  goal  analyzer  produces : 

( (HAS-GOAL-gaO  (planner-gaO  =  *USER*) 

(goal-gaO  =  (KNOW-gaO?  ()cnower-gaO  =  *USER*) 

(fact-gaO  =  STATE13?) ) ) ) ) 

UCEgo:  trying  to  find  effects  for  UNIX-RUPTIME-COMMANDO 
the  effects  are: 

( (HAS-EFFECT6-0  (command-of-ef fect6-0  =  (UNIX-RUPTIME-COMMANDO  &) ) 
(ef fect-of-command6-0  = 

(LIST-ACTION3-0  (list-loc3-0  = 

TERMINALl-0) 

(list-ob js3-0  = 

UP-TIMEl-0) ) ) ) 

(HAS-EFFECT7-0  (command-of-ef fect7-0  =  (UNIX-RUPTIME-COMMANDO  &) ) 
(ef  fect-of-coinmand7-0  = 

(LIST-ACTION4-0  (list-loc4-0  = 

TERMINALl-0) 

(list-ob j34-0  = 

NUMBERl-0) ) ) ) 

(HAS-EFFECT8-0  (command-of -effect 8-0  =  (UNIX-RUPTIME-COMMANDO  &) ) 
(ef fect-of-command8-0  = 

(LIST-ACTION5-0  (list-loc5-0  = 

TERMINALl-0) 

(list-ob js5-0  = 

LOAD-AVERAGEl-0) ) ) ) ) 


UCExpress :  Found  a  related  command,  so  creating  a  comparison 
between  UNIX-RUPTIME-COMMAND2  and  UNIX-UPTIME-COMMANDO 
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Express:  not  expressing  UNIX-RUPTIME -COMMANDO, 

since  it  is  already  in  the  context . 


The  generator  is  passed: 

(TELLS 

(effects  =  ( STATE-CHANGE 1  ( f inal-statel  =  (KNOW-gaO?  &) ) ) ) 
(listenerS-0  =  *USER*) 

(speakerS-0  =  UC) 

(propositions  = 

(HAS-EFFECT24 

(coiiiniand-of-effect2  4  =  (UNIX-RUPTIME-COMMANDO  &)  ) 

(ef  fect-of-conimand24  = 

(ANDO 

(stepO-0  =  (LIST-ACTION3-0 

(list-loc3-0  =  TERMINALl-0) 

(list-objs3-0  =  UP-TIMEl-0) ) ) 

(nextO-0  =  (ANDl  (stepl-0  =  (LIST-ACTION4-0 

(list-lOC4-0  =  TERMINALl-0) 
(list-objs4-0  =  NUMBERl-0))) 

(next 1-0  = 

(LIST-ACTIONS-0 
(list-locS-0  =  TERMINALl-0) 

(list-objsS-0  =  LOAD-AVERAGEl-0) ))))))))) 


ruptime  is  like  uptime,  except  ruptima  is  for  all  machines  on 
the  network. 


Figure  5.5.  UC  Session  showing  an  answer  that  contains  a  simile. 


The  processing  involves  comparing  the  effects  of  the  two  commands  and  noting 
where  they  differ.  In  the  above  example,  the  effects  of  uptime  are  to  list  the  uptime  of 
the  user’s  machine,  list  the  number  of  all  users  on  it,  and  list  its  load  average.  The  effects 
of  ruptime  are  similar  except  it  is  for  all  machines  on  the  user’s  network.  The  com¬ 
parison  algorithm  does  a  network  comparison  of  the  effects  of  the  two  commands.  A 
collection  of  differences  is  generated,  and  the  cost  of  expressing  these  differences  (meas¬ 
ured  in  number  of  concepts)  is  compared  with  the  cost  of  simply  stating  the  effects  of  the 
command.  If  expressing  the  differences  is  more  costly,  then  the  simile  format  is  not 
used.  On  the  other  hand,  if  expressing  the  differences  is  less  costly,  then  the  differences 
are  combined  into  a  shell  of  the  form  “<CommandA>  is  like  <CommandB>,  except 
[<CommandA>  also  ...]  [and]  [<CommandA>  does  not ...]  [and] ...” 


4.  Conclusion 
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4.1.  A  Comparison 

McKeown’s  TEXT  system  ([McKeown,  1985])  is  perhaps  the  closest  in  spirit  to 
UCExpress.  TEXT  provided  definitions  using  an  identification  schema.  This  is  similar 
to  UCExpress’  definition  format  except  TEXT  did  not  worry  about  how  much  informa¬ 
tion  to  convey.  TEXT  was  designed  to  always  produced  paragraph  length  descriptions, 
hence  it  was  not  overly  concerned  with  how  much  information  to  provide.  The  definition 
format  requires  more  knowledge  about  the  domain  in  order  to  select  the  most  relevant 
information  for  a  short  description. 

TEXT  also  used  a  compare  and  contrast  schema  to  answer  questions  about  the  differ¬ 
ences  between  objects  in  a  database.  This  is  similar  to  UCExpress  simile  format  except 
that  the  compare  and  contrast  schema  was  not  used  for  giving  descriptions  of  an  object  in 
terms  of  another  that  the  user  already  knew.  Since  TEXT  did  not  have  a  complete  model 
of  the  user,  it  was  unable  to  determine  if  the  user  already  knew  another  object  that  could 
be  contrasted  with  the  requested  object.  This  lack  of  a  user  model  was  also  evident  in  the 
fact  that  TEXT  did  not  provide  anything  similar  to  the  pruning  phase  of  UCExpress. 
Pmning  is  probably  more  relevant  in  a  conversational  context  such  as  UC  as  contrasted 
with  a  paragraph  generation  context  such  as  TEXT.  On  the  other  hand,  TEXT  was  able 
to  keep  track  of  the  conversational  focus  much  better  than  UC.  Focus  does  not  seem  to 
be  quite  as  essential  for  a  system  like  UC  that  gives  brief  answers. 

Other  related  research  include  work  on  using  examples  for  explanation  and  for  argu¬ 
ment  in  a  legal  domain  ([Rissland  et  al.,  1984]  and  [Rissland,  1983]).  The  difference 
between  those  examples  and  the  examples  created  by  UCExpress  is  that  Rissland’s 
examples  are  preformed  and  stored  in  a  database  of  examples  whereas  UCExpress 
creates  examples  interactively,  taking  into  account  user  provided  parameters.  Rissland’s 
HELP  system  dealt  only  with  help  about  particular  subjects  or  commands  rather  than 
arbitrary  English  questions  like  UC,  thus  HELP  did  not  have  to  deal  with  questions  such 
as  how  to  print  on  a  particular  printer.  Also  by  using  prestored  text,  HELP  was  not  con¬ 
cerned  with  the  problem  of  transforming  knowledge  useful  for  internal  computation  in  a 
planner  to  a  format  usable  by  a  generator. 

The  TAILOR  system  ([Paris,  1987])  used  a  idea  of  user  expertise  similar  to 
KNOME’s  to  tailor  explanations  to  the  user’s  level  of  expertise.  TAILOR  concentrated 
on  higher  level  strategies  for  explanation  than  UCExpress.  For  example,  TAILOR  used 
notions  of  the  user’s  level  of  expertise  to  choose  among  process-oriented  or  parts- 
oriented  description  strategies  in  building  up  a  paragraph.  TAILOR  could  also  mix  the 
two  types  of  strategies  within  a  paragraph  to  explain  different  aspects  of  a  system.  Such 
considerations  are  more  important  when  generating  longer  explanations  as  in  TAILOR, 
than  when  generating  brief  explanations  as  in  UCExpress. 

4.2.  Summary 

UC  separates  the  realization  of  speech  acts  into  two  processes:  deciding  how  to 
express  the  speech  act  in  UCExpress,  and  deciding  which  phrases  and  words  to  use  in 
UC’s  tactical  level  generator.  Through  this  separation,  the  pragmatic  knowledge  needed 


by  expression  is  separated  from  the  grammatical  knowledge  needed  by  generation. 
UCExpress  makes  decisions  on  pragmatic  grounds  such  as  the  conversational  context, 
the  user’s  knowledge,  and  the  ease  of  understand  of  various  expository  formats.  These 
decisions  serve  to  constrain  the  generator’s  choice  of  words  and  grammatical  construc¬ 
tions. 

Of  course,  it  is  sometimes  impossible  to  realize  all  pragmatic  constraints.  For 
example,  the  expression  mechanism  may  specify  that  a  pronoun  should  be  used  to  refer 
to  some  concept  since  this  concept  is  part  of  the  conversational  context,  but  this  may  not 
be  realizable  in  a  particular  language  because  using  a  pronoun  in  that  case  may  interfere 
with  a  previous  pronoun  (in  another  language  with  stronger  typed  pronouns,  there  may 
not  be  any  interference).  In  such  cases,  the  generator  needs  to  be  able  relax  the  con¬ 
straints.  UCExpress  allows  the  generator  to  relax  constraints  by  passing  to  the  generator 
all  of  the  conceptual  network  along  with  addition  pragmatic  markings  on  the  network. 
This  way,  the  generator  has  access  to  all  of  the  information  it  might  need  to  relax  the 
constraints  added  by  UCExpress. 
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Chapter  VI 

If-detected  Daemons 

The  heart  of  UCEgo’s  implementation  involves  the  use  of  if-detected  daemons. 
These  daemons  are  used  for  detecting  the  user’s  level  of  expertise  (see  Chapter  11,  Sec¬ 
tion  3),  for  goal  detection  (see  Chapter  III),  and  for  planning  (see  Chapter  IV).  All  of 
these  tasks  share  the  feature  that  they  require  that  the  system  perform  certain  actions  in 
appropriate  situations.  For  example,  UC  should  detect  goals  in  various  situations.  Plans 
should  be  suggested  in  other  classes  of  situations,  and  yet  other  situations  lead  KNOME 
to  make  inferences  about  the  user’s  knowledge.  Recognizing  these  classes  of  situations 
and  initiating  the  associated  action  is  done  by  if-detected  daemons. 

There  are  two  main  problems  in  recognizing  situations.  First  of  all,  situations  are 
difficult  to  detect,  because  they  consist  of  arbitrary  collections  of  external  and  internal 
state.  [Wilensky,  1983]  suggests  the  use  of  if-added  daemons  in  detecting  situations,  but 
pure  if-added  daemons  are  problematic,  because  they  can  only  detect  a  change  in  a  single 
state.  This  is  fine  for  situations  that  comprise  only  a  single  state.  However,  situations 
that  consist  of  many  states  in  conjunction  are  much  harder  to  detect,  because  the  various 
states  are  usually  not  realized  simultaneously.  Because  the  different  states  that  comprise 
a  situation  become  true  at  different  times,  an  if-added  daemon  that  was  activated  by  the 
addition  of  one  particular  state  would  always  need  to  check  for  the  co-occurrence  of  the 
other  states.  Also,  to  detect  a  multi-state  situation,  one  would  need  as  many  if-added 
daemons  as  states.  Each  if-added  daemon  would  be  slightly  different,  since  each  would 
need  to  check  for  a  slightly  different  subset  of  states  after  activation. 

The  other  problem  in  recognizing  situations  is  how  to  do  it  efficiently.  In  any  rea¬ 
sonably  complex  system,  there  are  a  very  large  number  of  possible  internal  and  external 
states.  Looking  for  cenain  situation  types  becomes  combinatorically  more  expensive  as 
there  are  more  possible  states  and  more  situation  types.  Parallel  processing  would  help, 
but  parallel  machines  are  not  yet  widely  available.  Even  with  parallel  machines,  optimi¬ 
zation  techniques  can  still  be  used  to  reduce  the  computational  complexity  considerably. 

This  chapter  describes  how  if-detected  daemons  can  recognize  multi-state  situation 
classes  and  how  they  are  implemented  in  an  efficient  manner  in  UC. 


1.  Structure  of  the  Daemon 

Like  all  daemons  ([Chamiak,  1972]),  if-detected  daemons  are  composed  of  two 
parts:  a  pattern  and  an  action.  For  if-detected  daemons,  these  are  called  the  detection-net 
and  the  addition-net  respectively,  since  both  the  pattern  and  action  in  if-detected  dae¬ 
mons  are  composed  of  KODIAK  networks  (see  Appendix  A).  These  daemons  work  by 
constantly  looking  in  UC’s  knowledge  base  for  a  KODIAK  network  that  will  match  its 
detection-net.  When  a  match  is  first  found,  the  daemon  adds  a  copy  of  its  addition-net  to 
UC’s  knowledge  base.  If-detected  daemons  are  said  to  be  activated  when  they  detect  the 
presence  of  some  set  of  KODIAK  network  in  UC  s  knowledge  base  that  matches  the 
daemon’s  detection-net.  Any  particular  set  of  network  is  allowed  to  activate  a  daemon 
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only  once.  This  avoids  the  problem  of  a  daemon  being  repeatedly  activated  by  the  same 
match. 

The  KODIAK  networks  of  the  detection-net  and  addition-net  are  not  distinct,  but 
rather  may  share  concepts/nodes  in  their  networks.  In  such  cases,  the  if-detected  daemon 
does  not  copy  the  shared  node  in  the  addition-net,  but  instead  uses  the  concept  that 
matched  the  shared  node.  A  simple  example  of  an  if-detected  daemon  whose  detection- 
net  and  addition-net  share  nodes  is  shown  in  Figure  6.1. 


Figure  6.1.  If-detected  daemon  for  handling  background  goal  sequences. 

Figure  6.1  shows  the  actual  form  of  the  daemon  as  it  is  entered  into  UC  using  the 
KODIAK  graphic  interface.  This  daemon  is  activated  whenever  UC  has  a  background 
goeil  that  is  a  goal  sequence.  In  such  cases,  UC  adopts  as  a  new  background  goal  the  first 
step  of  the  goal  sequence.  The  detection-net  of  the  daemon  is  composed  of  those  parts  of 
the  network  that  have  arrows  leading  into  the  double  circle  labeled  “if-detected”  plus  all 
concepts  that  are  either  its  aspectual-values  (i.  e.  the  values  of  its  aspectuals)  or  the 
aspectual-values  of  those  concepts,  recursively.  In  KODIAK  diagrams,  this  corresponds 
to  all  nodes  that  have  arrows  pointing  to  the  double  circle  or  that  can  be  reached  by  fol¬ 
lowing  arrows  away  from  those  concepts.  This  daemon’s  detection-net  consists  of  the 
concepts:  UC-HAS-GOAL3,  GOAL-SEQUENCE2,  STATUS2,  and  SOMETHING2. 
The  addition  net  is  similarly  depicted,  except  that  the  arrow  points  from  the  double-circle 
toward  the  initial  nodes.  In  this  case,  the  addition-net  consists  of  the  nodes:  UC-HAS- 
GOAL4,  STATUS2,  and  SOMETHING2.  Note  that  SOMETHING2  and  STATUS2  are 
shared  by  both  the  detection-net  and  the  addition-net.  So,  when  a  match  is  found,  the 
daemon  will  create  a  new  copy  of  UC-HAS-GOAL4  that  will  have  as  its  goal  whatever 
matched  SOMETHING2  and  as  its  status  whatever  matched  STATUS2. 

1.1.  Comparing  other  Daemons 

Although  if-detected  daemons  look  for  the  presence  of  particular  configurations  of 
KODIAK  network  in  UC’s  knowledge  base,  these  configurations  come  into  being 
predominandy"^  when  new  concepts  are  created  and  added  to  UC’s  knowledge  base, 

4  It  was  found  that  the  particular  if-detected  daemons  used  in  UC  were  not  being  ac¬ 
tivated  by  changes  in  the  values  of  aspectuals,  so  UC  was  optimized  to  not  look  for  this 
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rather  than  when  pre-existing  concepts  are  reconfigured  (e.  g.  by  changing  the  value  of  an 
aspectual).  In  this  sense,  if-detected  daemons  are  similar  to  if -added  daemons  ([Char- 
niak,  1972])  that  are  activated  when  adding  information  to  a  data-base.  The  difference  is 
that  if-added  daemons  look  only  for  the  addition  of  simple  patterns  to  the  data-base, 
whereas  if-detected  daemons  can  handle  arbitrary  conjunctions^  of  patterns.  So,  an  if- 
detected  daemon  may  be  activated  when  concepts  matching  only  a  small  portion  of  i\s 
detection-net  are  added  to  the  data-base,  provided  that  the  rest  of  the  detection-net  is 
already  matched  by  concepts  already  present  in  UC’s  knowledge  base. 

Another  consequence  of  handling  arbitrary  conjunctions  is  that  an  if-detected  dae¬ 
mon  may  be  activated  many  times  by  the  addition  of  only  one  datum  to  the  data-base. 
Such  cases  occur  when  that  part  of  the  detection-net  that  is  not  matched  by  the  added 
concept  matches  several  distinct  sets  of  concepts  in  UC’s  knowledge  base.  For  example, 
multiple  activations  can  occur  with  a  detection-net  consisting  of  a  conjunction  of 
independent  networks  that  we  will  refer  to  as  net-A  and  net-B.  Suppose  that  there  are 
several  conceptual  networks  in  the  data-base  that  match  net-A,  called  Al,  A2,  and  A3. 
Then,  when  a  conceptual  network,  Bl,  matching  net-B  is  added  to  the  data-base,  the  if- 
detected  daemon  will  activate  three  times,  once  each  for  Al  &  Bl,  A2  &  Bl,  and  A3  & 
Bl. 

If-detected  daemons  can  also  handle  negations.  This  means  that  the  daemon  is 
activated  by  the  absence  of  data  matching  the  pattern  that  is  negated.  Usually,  only  a 
part  of  the  daemon’s  detection-net  is  negated.  In  such  cases,  the  daemon  looks  for  the 
presence  of  concepts  matching  that  part  of  the  detection-net  that  is  not  negated,  and  Aen 
for  the  absence  of  concepts  matching  that  pan  of  the  detection-net  that  is  negated.  Since 
the  detection-net  and  addition-net  of  if-detected  daemons  are  both  KODIAK  networks, 
the  negated  parts  of  the  detection-net  may  shared  concepts/nodes  with  the  non-negated 
parts.  In  such  cases,  the  shared  nodes  serve  as  additional  constraints  on  the  negated  parts 
of  the  detection  net  in  that  the  daemon  need  only  detect  the  absence  of  KODIAK  network 
where  the  shared  nodes  have  been  replaced  by  their  matches. 

Although  if-detected  daemons  can  handle  both  conjunctions  and  negations  and  so 
should  be  able  to  detect  any  situation,  it  is  still  useful  to  have  procedural  attachment  for 
if-detected  daemons.  This  is  because  not  all  knowledge  is  represented  explicitly  in 
knowledge  bases;  some  knowledge  is  only  inferable  from  the  knowledge  bases.  Such 
inference  procedures  are  often  complex,  so  it  is  often  undesirable  to  encode  the  pro¬ 
cedures  as  daemons. 

An  example  of  a  daemon  with  an  attached  procedure  is  shown  in  Figure  6.2.  This 
daemon  detects  the  plan  of  having  UC  ask  someone  a  question  about  something,  when¬ 
ever  UC  believes  that  the  person  knows  what  UC  wants  to  know.  The  arrow  labeled 
“TEST”  indicates  a  procedure  attached  to  the  daemon.  In  this  case,  the  procedure  is  an 
instance  of  the  does-user-know?  procedure,  which  represents  a  call  to  KNOME,  UC’s 

type  of  activation.  Other  types  of  network  reconfiguration,  such  as  when  individual  con¬ 
cepts  are  concreted  (i.  e.  made  instances  of  more  specific  concepts  down  the  hierarchy), 
were  more  common. 

5  Disjunctions  can  be  handled  by  both  types  of  daemons  simply  by  splitting  the  dis¬ 
junction  into  two  daemons. 
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user  modeling  component  (see  Chapter  III).  This  call  is  necessary,  because  whether  or 
not  some  user  knows  some  fact  may  not  be  explicitly  represented  in  the  knowledge  base, 
but  may  instead  be  inferable  from  the  user’s  level  of  expertise.  Such  inferences  are  made 
by  the  does-user-know?  procedure  of  KNOME.  After  the  daemon  has  detected  that  UC 
has  the  goal  of  knowing  something  and  that  there  is  someone  present,  then  KNOME  is 
called  via  the  procedure  to  see  if  that  person  knows  what  UC  wants  to  know.  If  so,  then 
the  test  completes  the  activation  of  the  daemon,  and  the  plan  of  asking  that  person  in 
order  to  find  out  what  UC  wants  to  know  is  added  to  UC’s  knowledge  base. 


Figure  6.2.  If-detected  daemon  with  procedural  detection-net. 

Besides  calls  to  procedures  that  test  for  input,  if-detected  daemons  also  allow  calls 
to  procedures  in  their  output,  i.  e.  in  their  addition-nets.  An  example  of  this  is  shown  in 
the  if-detected  daemon  of  Figure  6.3.  This  if-detected  daemon  is  used  to  call  the  UNIX 
Planner  component  of  UC  whenever  UC  wants  to  know  some  way  to  do  something. 
UNIX-plannerl  is  a  kind  of  procedure  (i.  e.  it  is  an  instance  of  the  PROCEDURE 
category  in  KODIAK  terminology),  so  the  daemon  knows  that  it  should  not  just  copy  the 
node,  but  should  also  call  the  procedure  UNIX-planner  with  the  arguments  being  what¬ 
ever  matched  SOMETHING  1.  This  capability  of  if-detected  daemons  makes  them  less 
like  pure  daemons,  which  only  add  information  to  their  data-base,  and  makes  them  more 
like  production  systems.  The  essential  difference  is  that  if-detected  daemons  are  embed¬ 
ded  in  a  full  hierarchical  conceptual  network  representation  system,  namely  KODIAK, 
whereas  most  production  systems  allow  only  first-order  predicate  logic  representations. 
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Figure  6.3.  If-detected  daemon  with  ptiocedural  addition-net. 


1.2.  An  Example 

The  following  example  will  show  in  detail  how  if-detected  daemons  work.  Con¬ 
sider  the  if-detected  daemon  shown  in  Figure  6.4.  This  daemon  is  activated  whenever: 

1)  a  user  wants  to  know  something 

2)  UC  does  not  know  it 

3)  UC  wants  to  be  polite  to  the  user 

In  such  situations,  the  daemon  will  add  the  fact  that  a  plan  for  being  polite  to  the 
user  is  for  UC  to  apologize  to  the  user  for  not  knowing.  The  detection-net  of  the  daemon 
encodes  the  situation  and  consists  of  the  concepts:  HAS-GOALl,  KNOW2,  SOME¬ 
THING  1,  KNOWl,  UC,  FALSE,  UC-HAS-GOAL2,  TRUE,  BE-POLITEl,  and  USERl. 
The  addition-net  consists  of  the  concepts:  PLANFORl,  APOLOGIZEl,  UC,  USERl. 
KNOWl,  and  SOMETHINGl. 
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Figure  6.4,  If-detected  daemon  for  apologizing  when  UC  does  not  know  the  answer. 

This  daemon  might  be  activated  when  the  user  asks  UC,  “What  does  du  -r  do?” 
Although  UC  does  know  what  du  does,  it  does  not  know  what  du  -r  does.  Moreover, 
thanks  to  UC’s  meta-knowledge  (see  Chapter  HI,  Section  4),  UC  knows  that  it  does  not 
have  any  knowledge  about  the  options  of  du .  To  be  polite,  UC  apologizes  to  the  user  for 
not  knowing  what  du  -r  does.  Figure  6.5  shows  the  state  of  affairs  after  the  user  has 
asked  UC  the  question  and  UC’s  goal  analyzer  has  determined  the  user’s  goal.  The 
relevant  concepts  include  the  fact  that  UC  has  the  goal  of  being  polite  to  the  user  and  the 
fact  that  the  user  has  the  goal  of  knowing  the  effects  of  du  -r.  This  by  itself  is  not 
enough  to  cause  the  activation  of  the  daemon,  since  part  of  the  detection-net  does  not 
have  a  match,  namely  that  UC  does  not  know  the  effects  of  du  -r. 
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Figure  6.5,  Relevant  concepts  leading  up  to  activation  of  the  daemon. 

After  UC  has  tried  to  find  out  the  effects  of  du  -r  and  failed,  the  process  responsible 
notes  the  failure  by  adding  the  fact  that  UC  does  not  know  the  effects  to  UC’s  knowledge 
base.  The  relevant  concepts  are  shown  in  Figure  6.6.  This  completes  the  match  of  the 
daemon’s  detection  net.  UC-HAS-GOAL2  is  matched  by  UC-HAS-GOAL47;  BE- 
POLITEl?  is  matched  by  BE-POLITE5;  USERl?  is  matched  by  *USER*;  HAS- 
GOALl?  is  matched  by  HAS-GOAL-gaO;  KNOW2?  is  matched  by  KNOW-gaO;  SOME- 
THINGl?  is  matched  by  STATEll?;  and  KNOWl?  is  matched  by  KNOW47.  In  match¬ 
ing,  a  hypothetical  concept  (see  Appendix  A,  Section  2)  is  allowed  to  match  any  concept 
that  is  a  member  of  the  same  categories  as  the  hypothetical  concept.  The  matching  con¬ 
cept  is  also  allowed  to  be  a  member  of  more  categories  than  the  hypothetical  concept 
(since  KODIAK  has  multiple  inheritance),  and  is  also  allowed  to  be  a  member  of  more 
specific  sub-categories  than  the  hypothetical  concept.  For  example,  the  hypothetical  con¬ 
cept  SOMETHINGl?  can  be  matched  by  STATEll?,  because  STATE  is  a  more  specific 
sub-category  of  the  SOMETHING  category.  Concepts  such  as  UC,  TRUE,  and  FALSE 
in  the  detection-net  that  are  not  hypothetical  are  treated  as  constants  instead  of  as  vari¬ 
ables.  A  non-hypothetical  concept  can  only  match  itself.  For  example,  the  value  of  the 
truth-val  aspectual  of  whatever  matches  KNOWl?  must  be  FALSE,  because  FALSE  is 
not  a  hypothetical  concept  (see  Appendix  A,  Section  1  for  a  discussion  of  truth  values  in 
KODIAK). 
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Figure  6.6.  Relevant  concepts  completing  the  activation  of  the  daemon. 

One  disadvantage  of  using  the  hypothetical  marker  for  variables  is  that  it  is  hard  to 
specify  that  the  matching  concept  must  be  a  hypothetical  concept.  This  problem  is 
solved  by  adding  the  new  marker  MAYBE  exclusively  for  this  purpose.  Thus  SOME¬ 
THING  1?  is  marked  as  dominated  by  MAYBE  in  the  detection-net  of  the  daemon.  This 
adds  the  requirement  that  whatever  matches  SOMETHING  1?  must  also  be  hypothetical. 
So,  STATEl  1?  can  match  SOMETHINGl?,  only  because  it  is  indeed  hypothetical. 

After  the  match,  the  daemon  adds  a  copy  of  its  addition-net  to  UC  s  knowledge 
base.  The  output  of  this  daemon  in  this  example  is  shown  in  Figure  6.7.  Concepts  that 
are  shared  between  the  addition-net  and  the  detection-net  are  not  copied.  Rather,  the 
corresponding  matching  concept  is  used  instead.  An  example  of  a  shared  concept  is  BE- 
POLITEl?,  which  was  matched  by  BE-POLITE5.  The  copy  of  the  addition-net  shown  in 
Figure  6.7  shows  that  BE-POLITE5  is  used  directly.  Hypothetical  concepts  that  are  not 
shared  are  copied,  and  non-hypothetical  concepts  are  used  directly.  Copying  hypotheti¬ 
cal  concepts  in  the  addition-net  means  creating  new  concepts  that  are  dominated  by  the 
same  categories  as  the  old  concepts  except  for  the  hypothetical  marker.  In  those  cases 
where  one  desires  the  new  copy  to  also  be  hypothetical,  the  MAYBE  marker  can  be  used 
to  mean  that  the  copy  should  also  be  made  hypothetical.  This  is  analogous  to  the  use  of 
MAYBE  in  detection-nets. 


4. 


4. 


W 


-  160- 


APOLOCteE2 


listenei2 


♦USER* 


plan60 


PLANF0R6O 


goals60 


BE-POl 


is-polite5 


UC 


;er2-2 


poUte-to5 


UC 


a^ogy2 


♦USER* 


FALSE 

knower47  ^ 
jslatus47-0 


Figure  6.7.  Output  from  the  daemon:  a  copy  of  its  addition-net  for  UC’s  knowledge  base. 


2.  Implementation  Strategies 


The  simplest  way  to  activate  daemons  is  the  simple  production  system  method, 
which  loops  through  ail  the  daemons  and  performs  matching  to  determine  which  dae¬ 
mons  should  be  activated.  This  scheme  takes  increasingly  more  processing  time  as  the 
number  of  daemons  increases  and  as  the  size  of  the  data-base  increases.  Theoretically, 
every  daemon’s  pattern  would  need  to  be  matched  against  every  piece  of  information  in 
the  data-base.  The  processing  cost  for  if-detected  daemons  is  especially  high,  because 
if-detected  daemons  have  complex  detection-nets  that  consist  of  combinations  of  possi¬ 
bly  independent  concepts.  For  if-detected  daemons,  each  independent  concept  in  the 
detection-net  needs  to  be  matched  against  every  entry  in  the  data-base.  The  processing 
cost  for  large  numbers  of  if-detected  daemons  and  very  large  data-bases  becomes  prohi¬ 
bitive  when  real-time  response  is  needed  as  in  UC. 

Actual  production  systems  have  addressed  the  problem  of  efficiency  with  a  variety 
of  methods.  These  methods  cannot  be  directly  applied  to  if-detected  daemons,  because 
daemons  differ  in  several  important  aspects  from  the  rules  in  most  production  systems 
(some  of  the  ideas  can  be  modified  to  apply,  and  these  are  described  later).  First,  if- 
detected  daemons  use  a  semantic  network  representation  (KODIAK),  whereas  most  pro¬ 
duction  systems  do  not  (an  exception  is  described  by  [Duda  et  al,  1978]).  As  a  result, 
if-detected  daemons  can  take  advantage  of  the  multiple  inheritance  taxonomies  of  seman¬ 
tic  network  representations  and  can  more  easily  use  the  same  relation  in  several  different 
patterns  and  actions.  Also,  instead  of  variables,  if-detected  daemons  use  the  hypothetical 


marker,  which  allows  nodes  in  the  detection-net  to  match  any  concept  in  the  knowledge 
base  that  is  lower  in  the  KODIAK  hierarchy.  Since  ordinary  production  systems  only 
allow  specific  tokens  at  the  top-level  of  their  patterns,  they  would  need  many  more  rules 
to  encode  the  same  information  as  one  if-detected  daemon.  Finally,  if-detected  daemons 
are  designed  to  operate  in  parallel,  whereas  most  production  systems  require  a  conflict 
resolution  mechanism  to  determine  which  of  several  conflicting  rules  should  be  activated. 

Since  if-detected  daemons  are  designed  to  activate  in  parallel,  the  best  solution  to 
the  problem  of  efficiency  would  be  to  perform  the  match  testing  of  different  daemons  in 
parallel.  Unfortunately,  parallel  machines  that  run  LISP  (the  implementation  language 
for  UC)  are  not  yet  readily  available.  Even  with  parallel  LISP  machines,  some  optimiza¬ 
tions  are  still  useful  for  improving  speed  and  efficiency.  This  section  will  discuss  the 
variety  of  such  optimizations  and  how  they  might  be  implemented  to  considerably 
improve  the  performance  of  if-detected  daemons. 

One  possible  optimization  in  the  processing  of  if-detected  daemons  involves  taking 
advantage  of  the  organization  of  the  data-base  to  limit  the  search  for  matches.  This  is 
called  the  data-base  retrieval  optimization.  For  AI  knowledge  bases  that  are  organized 
in  inheritance  hierarchies,  this  means  restricting  candidates  for  matching  to  only  those 
concepts  that  are  in  the  same  part  of  the  inheritance  hierarchy  as  the  concepts  in  the 
detection- net.  For  example,  when  looking  for  a  match  for  HAS-GOALl?,  the  matcher 
need  only  look  at  instances  of  HAS-GOAL,  and  instances  of  HAS-GOAL’s  sub¬ 
categories  (which  in  this  case  includes  only  UC-HAS-GOAL).  This  simple  optimization, 
which  is  commonly  used  in  data-base  retrieval,  considerably  restricts  the  size  of  the  ini¬ 
tial  set  of  candidates. 

2.1.  Distributed  Data-Driven  Activation 

Another  possible  optimization  for  the  implementation  of  if-detected  daemons  is  to 
perform  the  match  testing  for  only  those  daemons  that  are  probable  candidates  for  activa¬ 
tion.  This  may  seem  impossible,  since  it  would  be  hard  to  tell  whether  a  daemon  is  a 
probable  candidate  for  activation  without  looking  at  it  first.  However,  the  data-base 
retrieval  optimization  can  be  used  in  reverse.  Rather  than  looking  in  the  knowledge  base 
hierarchy  for  candidates,  one  can  look  in  the  hierarchy  for  matching  detection-net  con¬ 
cepts,  when  one  changes  the  knowledge-base.  This  technique  is  called  distributed  data- 
driven  activation.  It  is  data-driven,  since  one  looks  for  daemons  to  activate  as  data  is 
changed  (i.  e.  added,  deleted,  or  modified).  It  is  distributed,  since  any  particular  piece  of 
newly  changed  data  may  only  match  part  of  the  detection-net  of  a  daemon.  The  rest  is 
matched  by  either  previously  changed  data  or  subsequent  changes  to  the  data-base. 

Distributed  data-driven  activation  is  similar  to  techniques  used  in  production  sys¬ 
tems  to  increase  their  efficiency.  The  Rete  Match  Algorithm  that  is  used  in  OPS5  (see 
[Forgy,  1982])  extracts  features  from  the  patterns  of  rules  and  forms  a  discrimination  net 
of  features  that  is  used  for  matching  patterns.  When  elements  are  added  to  or  removed 
from  working  memory,  OPS5  uses  this  precompiled  discrimination  net  to  match  produc¬ 
tion  rules.  [McDermott  et  al.,  1978]  showed  that  by  using  pattern  features  to  index  into 
rules,  the  estimated  cost  of  running  a  production  system  can  be  improved  so  that  the  run 
time  is  almost  independent  of  the  number  of  productions  and  number  or  working  memory 
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elements.  Distributed  data-driven  activation  is  different  from  these  schemes  in  that  it 
uses  the  multiple  inheritance  hierarchy  of  KODIAK  to  index  into  if-detected  daemons. 
Nevertheless,  the  main  idea  of  distributed  data-driven  activation  is  similar  to  production 
system  methods  like  the  Rete  Algorithm. 

To  see  how  distributed  data-driven  activation  works,  consider  what  might  happen 
when  a  new  instance  of  HAS-GOAL,  HAS-GOALl,  is  added  to  a  knowledge  base.  This 
new  instance  can  only  cause  the  activation  of  those  daemons  that  have  detection-nets  that 
might  match  HAS-GOALl.  Detection-net  concepts  that  might  match  HAS-GOALl 
include  hypothetical  instances  of  HAS-GOAL  or  hypothetical  instances  of  any  of  the 
parent  categories  of  HAS-GOAL  (i.  e.  M-POSSESS,  STATE,  and  SOMETHING).  This 
is  just  the  reverse  of  the  process  used  in  the  data-base  retrieval  optimization.  In  that  case, 
one  starts  from  the  detection-net  and  looks  down  the  conceptual  hierarchy  for  possible 
matches,  whereas  here  one  starts  from  the  potential  match  and  looks  up  the  conceptual 
hierarchy  for  hypothetical  concepts  that  are  in  detection-nets. 

A  small  optimization  for  speeding  up  the  lookup  is  to  precompile  a  list  for  every 
category  of  those  instances  that  are  part  of  some  detection-net  This  way,  whenever  a 
new  instance  is  added,  one  can  just  look  in  the  list  to  see  which  daemons  might  possibly 
be  affected.  Such  precompilation  can  be  done  when  daemons  are  first  defined  in  the  sys¬ 
tem. 

Another  small  optimization  is  to  check  for  a  match  only  when  all  the  nodes  of  a 
detection-net  have  been  primed  \  that  is,  marked  as  having  potential  matches.  This  way, 
when  a  new  concept  primes  one  node  of  a  detection-net,  one  can  check  to  see  if  aU  of  the 
other  nodes  have  been  primed  before  trying  to  match  the  entire  detection-net.  If  not  all 
of  the  nodes  of  the  detection-net  have  been  primed,  no  matching  is  needed  yet,  since 
there  will  be  nothing  in  the  knowledge  base  that  will  match  the  unprimed  nodes.  If  there 
were  potential  matches  for  these  unprimed  nodes  then  they  would  have  been  primed 
when  the  potential  matches  were  added  to  the  knowledge  base.  This  optimization  works 
well  when  a  system  is  just  starting  up.  However,  as  more  concepts  are  created,  more  of 
the  nodes  of  a  detection-net  will  have  potential  matches,  and  so  more  daemons  will 
become  fully  primed  (i.  e.  all  of  the  nodes  of  its  detection-net  have  been  primed).  Once 
a  daemon  becomes  fully  primed,  any  single  new  concept  that  primes  a  detection-net  node 
will  require  matching.  It  is  not  possible  to  reset  the  primes  after  activation,  because  it  is 
always  possible  that  a  new  concept  in  conjunction  with  many  old  concepts  might  cause 
the  activation  of  a  daemon.  This  optimization  is  worthwhile  in  systems  such  as  UC 
where  sessions  with  users  are  brief  enough  so  that  many  daemons  remain  unprimed  for  a 
significant  part  of  the  session. 

One  of  the  advantages  of  distributed  data-driven  activation  is  that  it  does  away  with 
the  some  of  the  bookkeeping  needed  in  the  production  system  loop  method.  Since  dae¬ 
mons  can  only  be  activated  by  changes  in  the  knowledge  base,  the  search  can  no  longer 
find  something  that  was  a  previous  match.  Thus,  the  system  no  longer  needs  to  keep 
around  a  list  of  previous  matches  to  avoid  multiple  activations  of  a  daemon  on  the  same 
concepts. 
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2.2.  Delayed  Matching 


Another  optimization  technique  involves  reducing  the  frequency  of  the  activation 
process.  In  the  simple  production  system  loop,  the  processing  costs  can  be  reduced  by 
performing  the  loop  less  frequently.  For  example,  rather  than  executing  the  loop 
immediately  whenever  something  changes  in  the  knowledge  base,  the  system  can  wait 
and  execute  the  loop  at  fixed  times.  This  way,  one  loop  through  the  daemons  can  catch 
many  different  activations.  This  delaying  tactic  does  not  work  if  the  system  expects  the 
daemons  to  be  activated  immediately.  However  in  many  applications  such  as  UC, 
immediate  activation  of  daemons  at  an  atomic  level  is  not  needed.  For  example,  in  UC 
the  activation  of  daemons  can  wait  until  after  UC’s  parser/understander  finishes  creating 
the  KODIAK  network  that  represents  the  user’s  input.  It  is  not  necessary  to  activate  dae¬ 
mons  as  soon  as  the  understander  creates  another  KODIAK  concepts,  because  there  are 
no  daemons  that  influence  the  understander.  Activating  daemons  at  the  end  of  the 
parsing/understanding  process  is  good  enough  for  the  other  components  of  UC. 

The  same  delaying  optimization  can  be  applied  to  the  distributed  data-driven  activa¬ 
tion  scheme.  Instead  of  testing  the  detection-net  of  a  daemon  for  a  match  as  soon  as  its 
nodes  have  been  primed,  the  testing  for  a  match  can  be  delayed  provided  that  the  system 
remembers  the  priming  concepts.  Then  all  the  matching  can  be  performed  at  a  later  time 
to  save  work.  By  delaying  the  matching  as  long  as  possible,  the  system  is  given  time  to 
complete  the  match.  For  example,  consider  the  case  of  a  detection-net  that  consists  of  a 
single  relation,  Rl?,  that  relates  two  concepts,  Al?  and  Bl?.  Suppose  further  that  this 
daemon  is  fully  primed,  that  is  there  are  potential  matches  for  Rl?,  Al?,  and  Bl?.  Then 
suppose  that  the  system  creates  the  matching  concepts  A2,  B2  and  R2  where  R2  relates 
A2  to  B2.  If  the  system  adds  each  of  these  concepts  to  the  knowledge  base  at  separate 
times  (which  is  not  unlikely),  then  the  system  will  have  to  try  to  match  the  detection-net 
after  adding  each  concept.  This  is  necessary  because  the  new  concept  could  potentially 
match  the  detection- net  in  conjunction  with  other  older  concepts  that  primed  the  other 
nodes  of  the  detection-net.  For  example  is  A2  is  added  first,  then  the  system  will  have  to 
try  matching  Al?  to  A2,  Bl?  to  its  old  primes  and  R2?  to  its  old  primes.  Since  none  of 
the  old  primes  of  R2?  will  relate  A2,  the  match  will  fail.  This  will  be  repeated  again 
when  B2  is  added  and  when  R2  is  added.  Thus  the  system  will  have  to  try  matching  the 
detection  net  as  many  times  as  priming  concepts  are  added  to  the  knowledge  base.  How¬ 
ever,  if  matching  can  be  delayed  until  all  of  the  pertinent  concepts  have  been  added,  then 
the  system  will  have  to  go  through  the  matching  process  only  once. 

In  practice,  the  delaying  optimization  saves  considerable  work.  However  there  is 
some  minor  additional  bookkeeping  needed.  The  system  needs  to  keep  track  of  which 
concepts  have  primed  which  detection-net  nodes  since  the  last  time  matching  was  done. 
The  system  also  needs  to  keep  track  of  which  daemons  with  fully  primed  detection-nets 
have  been  primed  since  the  last  matching  cycle.  Since  the  system  already  keeps  track  of 
the  new  priming  concepts,  it  becomes  easy  to  keep  a  list  of  old  primes  also.  This  way, 
the  system  no  longer  needs  to  look  in  the  conceptual  hierarchy  for  potential  matches  (the 
data-base  retrieval  optimization).  This  optimization  is  a  space-time  tradeoff,  since  keep¬ 
ing  a  list  of  old  primes  takes  up  more  space  while  looking  in  the  hierarchy  takes  more 

time. 
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3.  UC’s  Implementation 

The  actual  implementation  of  if-detected  daemons  in  UC  uses  a  distributed  data- 
driven  activation  scheme  with  delayed  matching.  When  UC  is  created,  the  if-detected 
daemons  are  entered  into  UC  after  all  KODIAK  categories  have  been  defined  in  UC. 
Preprocessing  of  daemons  involves  creating  Sl  fast-access  list  for  each  category  (except 
the  SOMETHING  category)  consisting  of  those  detection-net  nodes  that  are  hypothetical 
and  that  are  members  of  that  category.  These  lists  are  stored  under  the  categories’  pro¬ 
perty  lists  and  are  used  to  speed  up  access  when  priming  the  detection-net  nodes.  The 
SOMETHING  category  includes  everything  in  UC’s  knowledge  base,  so  the  fast-access 
list  for  the  SOMETHING  category  is  simply  a  pointer  to  the  list  of  all  concepts  in  the 
knowledge  base. 

During  the  execution  of  UC,  processing  of  if-detected  daemons  occurs  in  the  two 
distinct  phases  in  a  delayed  matching  scheme.  The  two  phases  are  priming  and  match¬ 
ing.  Each  phase  is  described  below. 

3.1.  Priming 

Priming  of  detection-net  nodes  is  performed  whenever  concepts  are  created  or 
modified  in  UC.  Since  all  KODIAK  concepts  in  UC  are  stored  in  UC’s  knowledge  base, 
there  is  no  distinction  made  between  creating  concepts  and  adding  concepts  to  the 
knowledge  base.  When  a  concept  is  created  or  modified,  it  primes  all  matching 
detection-net  nodes.  Detection-net  nodes  are  found  by  looking  in  the  fast-access  lists 
stored  under  the  concept’s  immediate  categories  and  all  their  dominating  categories  up 
the  conceptual  hierarchy.  A  special  case  is  made  for  those  concepts  that  are  modified  by 
concreting  them,  that  is  making  them  members  of  more  specific  categories  than  their  pre¬ 
vious  categories.  In  these  cases,  the  modified  concept  will  already  have  primed  its  old 
categories  (and  their  dominating  categories)  at  the  time  that  the  modified  concept  was 
first  created  or  last  modified.  Hence  the  modified  concept  should  not  prime  these  old 
categories  to  avoid  multiple  primings. 

Priming  involves  storing  the  new/modified  concept  under  the  primed  node’s  list  of 
priming  concepts  (kept  on  the  primed  node’s  property  list).  After  priming  a  node  of  a 
daemon’s  detection-net,  the  priming  process  checks  to  see  if  all  of  the  other  nodes  of  that 
daemon’s  detection-net  have  been  primed.  If  so,  the  fully  primed  daemon  is  added  to  a 
global  list  of  daemons  to  be  checked  during  the  next  matching  phase.  The  initial  version 
of  UC’s  priming  mechanism  was  coded  by  Lisa  Rau  who  has  since  appUed  a  form  of 
priming  and  matching  to  information  retrieval  from  story  data-bases  in  the  SCISOR  sys¬ 
tem  ([Rau,  1987a]  and  [Rau,  1987b]).  Unlike  UC,  SCISOR’ s  priming  system  is  a  true 
marker  passing  scheme,  and  matching  in  SCISOR  is  used  to  rate  the  similarity  of  the 
retrieved  networks  to  the  priming  network.  In  SCISOR,  there  is  no  sense  of  additional 
inferences  beyond  unification  of  the  matched  networks  such  as  those  in  the  addition-nets 
of  if-detected  daemons. 
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3.2.  Matching 

The  matching  phase  in  UC  occurs  at  distinct  points  in  UC’s  processing:  before  UC’s 
parser/understander,  before  UC’s  goal  analyzer,  and  after  the  goal  analyzer.  Each  match¬ 
ing  phase  is  actually  a  loop  that  goes  through  the  global  list  of  fully-primed  daemons 
(collected  during  the  priming  phase)  and  tests  them  for  matches.  After  testing  every  dae¬ 
mon  for  matches,  the  addition-nets  of  the  successfully  matched  daemons  are  copied  and 
added  to  UC’s  knowledge  base.  Theoretically,  matching  for  each  daemon  can  be  done  in 
parallel,  although  in  practice  UC  runs  on  sequential  machines.  Likewise,  copying  the 
addition-nets  can  be  done  in  parallel. 

As  the  addition-nets  are  copied  and  added  to  UC’s  knowledge  base  (actually  an 
atomic  operation,  since  all  KODIAK  concepts  are  added  to  UC’s  knowledge  base  as  soon 
as  they  are  created),  priming  may  occur,  because  the  knowledge  base  is  being  modified. 
These  copies  of  addition-nets  can  in  turn  (possibly  in  conjunction  with  older  concepts) 
cause  more  daemons  to  become  fully  primed.  Hence  after  copying  all  of  the  appropriate 
addition-nets,  the  matching  process  begins  anew.  This  loop  continues  until  there  are  no 
more  daemons  that  have  been  fully  primed  waiting  to  be  matched. 

Testing  for  matches  in  UC  involves  three  phases.  First,  the  non-negated  parts  of  the 
detection-net  are  matched.  If  matching  is  successful,  then  the  negated  parts  of  the 
detection-net  are  checked.  Finally  if  both  previous  steps  succeed,  the  daemon  s  pro¬ 
cedural  tests  are  examined.  If  all  three  phases  succeed,  then  the  assoc  list  of  detection- 
net  nodes  and  their  matches  are  stored  for  later  use  in  copying  the  addition-net.  The 
addition-nets  of  activated  daemons  are  not  copied  until  the  system  has  finished  the  match 
testing  for  all  fully  primed  daemons.  In  theory,  this  prevents  a  copy  of  the  addition-net 
of  one  daemon  from  invalidating  the  match  of  another  daemon.  In  practice,  the  situa¬ 
tions  encoded  in  UC’s  daemons  do  not  have  such  interaction  problems. 

Copying  addition-nets  is  fairly  straightforward.  The  detection-net  is  traversed  and 
nodes  are  processed  as  follows: 

1)  Nodes  found  in  the  assoc  list  that  was  created  during  matching  are  re¬ 
placed  by  their  matches. 

2)  Nodes  that  are  hypothetical,  but  not  in  the  assoc  list,  are  replaced  by  a 
copy. 

3)  Nodes  that  are  non-hypothetical  are  replaced  by  themselves. 

After  copying  the  detection-net,  those  nodes  that  are  procedures  (i.  e.  instances  of 
PROCEDURE  or  a  sub-category  of  PROCEDURE)  are  also  executed.  The  name  of  the 
lisp  function  to  call  is  given  by  the  named  of  the  procedure  node,  and  the  arguments  are 
given  by  its  aspectuals.  Some  of  these  procedures  include  calls  to  UC’s  UNIX  planner 
component,  calls  to  UC’s  generator  component,  and  calls  to  exit  UC  (see  Chapter  IV, 
Section  4.2). 
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3.3.  An  Example 


A  simple  example  will  show  how  if-detected  daemons  are  actually  processed  in  UC. 
The  if-detected  daemon  shown  in  Figure  6.8  is  used  to  call  KNOME  via  the  procedure 
user-knows,  whenever  UC  encounters  the  situation  where  some  person  (PERSONl) 
wants  (HAS-GOALl)  to  know  (KNOWl)  something  (SOMETfflNGl),  and  that  person 
is  not  UC  (implemented  by  the  NOT  test  which  checks  to  make  sure  that  HAS-GOALl  is 
not  a  UC-HAS-GOAL).  This  daemon  is  typically  activated  when  UC’s  goal  analysis 
component  determines  that  the  user  has  the  goal  of  knowing  something.  The  arguments 
of  the  user-knows  procedure  include  the  user,  what  the  user  wanted  to  know,  and 
FALSE,  which  indicates  that  KNOME  should  infer  that  the  user  does  not  know. 


Figure  6.8.  Daemon  16:  call  KNOME  when  someone  wants  to  know  something. 

Figure  6.9  shows  a  trace  of  a  UC  session  in  which  this  daemon  is  activated.  When 
the  user  asks,  “How  can  I  delete  a  file?”  UC’s  goal  analyzer  determines  that  the  user  has 
the  goal  (HAS-GOAL-gaO)  of  knowing  (KNOW-gaO)  how  to  delete  a  file  (ACTION12). 
When  UC’s  goal  analyzer  creates  the  concepts  that  encode  this  inference,  the  concepts 
prime  other  related  concepts  in  the  detection-net  of  if-detected  daemons.  HAS-GOAL- 
gaO  primes  a  number  of  concepts  in  if-detected  daemons.  Among  these  is  HAS-GOALl, 
which  is  in  the  detection  net  of  the  daemon  shown  in  Figure  6.8.  When  HAS-GOALl  is 
primed  by  HAS-GOAL-gaO,  HAS-GOAL-gaO  is  added  to  the  list  of  primers  of  HAS- 
GOALl  that  is  stored  under  HAS-GOALl ’s  property  list.  The  reason  why  the  trace  mes¬ 
sage  about  priming  occurs  before  the  trace  message  about  the  goal  analyzer’s  output  is 
because  priming  is  an  atomic  operation  integrated  within  creation  of  KODIAK  concepts. 
As  the  goal  analyzer  creates  concepts,  priming  occurs  and  trace  messages  about  priming 
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are  output.  The  trace  message  about  what  the  goal  analyzer  produces  is  not  output  until 
after  the  goal  analyzer  has  finished  creating  concepts. 


Welcome  to  UC  (Unix  Consultant)  version  3.23 
To  a  pronpt,  please  type  in  your  questions 

about  the  UNIX  file  system  in  English. 

To  leave,  just  type  ' or  ' (exit) '  . 

Hi. 

How  can  I  help  you? 

#  How  can  1  delete  a  file? 


Marking 

Marking 

Marking 

Marking 

Marking 

Marking 

Marking 

Marking 


KAS—GCAL4  as  primed,  by  KAS—GCAL— gaO 
daemon32  as  fully  primed 
HAS-G0AL3  as  primed  by  HAS-GOAL-gaO 
daemon24  as  fully  primed 
HAS-G0AL2  as  primed  by  HAS-GOAL-gaO 
daemon23  as  fully  primed 
HAS-GOALl  as  primed  by  HAS-GOAL-gaO 
daemonl6  as  fully  primed 


Daemonl6  is  the  daemon  shown  in  Figure  6.8. 

Marking  HAS-GOALO  as  primed  by  HAS-GOAL-gaO 
Marking  daemonO  as  fully  primed 


The  goal  analyzer  produces: 

( (HAS-GOAL-gaO  (planner-gaO  =  *USER*) 
(goal-gaO  = 
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(KNOW-gaO? 


(knower-gaO  =  *USER*) 

(fact-gaO  =  (ACTION12?  &)))))) 


UCEgo  detects  the  following  concepts: 

(HAS-GOAL-gaO  &) 

and  asserts  the  following  concept  into  the  database: 
(user-knows8  (uk-user8  =  *USER*) 

(uk-truth-val8  =  FALSE) 

{uk-fact8  =  (ACTION12?  &) ) ) 

KNOME:  Asserting  *USER*  does  not  know  ACTION12? 


Use  rm. 

For  exan^le,  to  delete  the  file  named  foo,  type  'rm  foo' . 


Figure  6.9.  Trace  of  concept  priming  leading  to  the  activation  of  a  daemon. 


The  priming  of  HAS -GOAL  1  completes  the  priming  of  its  daemon,  which  is  labeled 
daemon  16.  Daemon  16  is  added  to  the  global  list  of  fully  primed  daemons  for  processing 
during  the  delayed  matching  phase.  The  first  such  matching  phase  occurs  after  UC’s  goal 
analyzer  has  finished.  In  the  matching  phase,  the  detection  nets  of  all  fully  primed  dae¬ 
mons  are  checked  for  matches.  Daemon  16  is  one  of  these,  so  HAS-GOALl  is  matched 
against  HAS-GOAL-gaO.  Since  both  are  instances  of  HAS-GOAL,  the  two  match  at  the 
top  level,  so  matching  continues  with  their  aspectuals.  HAS-GOALl’s  goal1  aspectual 
has  the  value  KNOWl,  which  is  matched  against  the  value  of  HAS-GOAL-gaO ’s  goal 
aspectual,  KNOW-gaO.  Both  are  instances  of  KNOW,  so  their  aspectuals  are  checked. 
PERSONl,  the  knower  of  KNOWl,  matches  *USER*,  the  knower  of  KNOW-gaO;  and 
SOMETHINGl,  the  fact  of  KNOWl,  matches  ACTION12,  the  fact  of  KNOW-gaO. 
Finally  the  planner  aspectual  of  HAS-GOALl  is  matched  against  the  planner  aspectual 
of  HAS-GOAL-gaO.  In  this  case,  PERSONl  has  already  been  matched  with  *USER*,  so 
the  planner  of  KNOW-gaO  must  also  be  *USER*  for  a  proper  match.  This  is  indeed  the 
case,  so  the  detection-net  of  daemon  16  is  completely  matched  and  daemon  16  is 
activated. 

Daemon  16  is  activated  by  creating  a  copy  of  its  addition-net,  which  consists  of 
user- knows  1  with  aspectuals  and  values;  uk-fact1  =  SOMETHINGl,  uk-user1  —  PER¬ 
SONl,  and  uk-truth-val1  =  FALSE.  Since  user-knows1  is  hypothetical,  a  new  copy  of 
us0r-knows1  is  created.  This  is  shown  in  the  trace  as  user-knows8.  Next  its  aspectuals 
are  copied.  The  uk-fact1  aspectual  has  the  value  SOMETHINGl,  which  is  also 
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hypothetical.  However,  SOMETHINGl  was  previously  unified  with  ACTION12,  so 
instead  of  creating  a  new  copy  of  SOMETHINGl,  the  unified  concept,  ACTION12  is 
used  instead.  Similarly,  PERSONl  was  unified  with  *USER*,  so  uk-userS  gets  the 
value  *USER*.  On  the  other  hand,  the  value  of  uk-truth-val1  is  not  hypothetical,  so  its 
value,  FALSE,  is  used  directly  for  the  value  of  uk-truth-val8 .  In  the  trace,  the  new  copy 
of  user-knowsl,  user-knows8,  is  noted  as  being  asserted  into  the  database. 

Since  user-knows  is  a  procedure  (i.  e.  it  is  dominated  by  the  PROCEDURE 
category),  UCEgo  next  calls  the  user-knows  procedure  with  arguments  *USER*, 
ACTION12,  and  FALSE.  User-knows  is  an  entry  to  the  KNOME  component  for  infer¬ 
ring  a  user’s  knowledge  state.  In  this  case,  KNOME  asserts  that  the  user  does  not  know 
how  to  delete  a  file  (ACTION12).  Later  (not  shown)  after  UC’s  UNIX  planner  has  deter¬ 
mined  that  a  plan  for  deleting  a  file  is  to  use  the  rm  command,  KNOME  will  figure  out 
that  the  user  does  not  know  rm.  Finally,  after  more  priming  and  matching,  UC  produces 
its  answer,  and  tells  the  user  to  use  rm  (usually  giving  an  example  of  using  rm  also). 
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Chapter  VII 
Conclusions 


1,  Summary 

The  examples  presented  in  this  thesis  demonstrate  that  a  natural  language  interface 
needs  to  be  an  intelligent  agent  in  order  to  respond  properly  to  its  user.  An  intelligent 
agent  based  on  goals  and  plans  is  the  most  flexible,  because  such  a  system  can  more 
easily  detect  positive  and  negative  goal  interactions.  Within  this  planning  paradigm,  the 
key  problem  for  building  an  intelligent  agent  is  how  to  detect  the  right  goals  for  the 
agent  in  appropriate  situations .  Once  an  agent  has  adopted  appropriate  goals,  planning 
to  satisfy  those  goals  is  relatively  better  understood  problem. 

Detecting  situations  in  which  an  agent  should  detect  new  goals  is  a  difficult  prob¬ 
lem,  because  such  situations  can  consist  of  arbitrary  collections  of  external  and  internal 
states.  For  an  agent  that  serves  as  a  natural  language  interface  for  a  user,  a  large  part  of 
the  agent’s  external  state  information  will  be  concerned  with  the  mental  state  of  the  user. 
Hence,  such  agents  need  to  contain  a  model  of  the  user.  Furthermore,  if  the  agent  is  a 
consultant  system  whose  main  purpose  is  to  impart  its  expertise  to  the  user,  then  the 
agent  needs  to  model  the  knowledge  and  beliefs  of  the  user. 

In  the  UC  system,  the  UCEgo  component  implements  an  intelligent  agent,  and  the 
KNOME  component  models  the  knowledge  and  beliefs  of  the  user.  KNOME  models 
users  using  a  double-stereotype  system  with  a  range  of  stereotype  categories  representing 
the  expertise  of  users  and  a  range  of  difficulty  levels  for  UNIX  information.  KNOME 
deduces  particular  facts  about  what  a  user  knows  during  the  dialog  with  the  user,  and 
uses  these  facts  along  with  other  clues  to  deduce  the  expertise  level  of  a  user. 

The  UCEgo  component  creates  and  carries  out  plans  to  satisfy  goals,  which  it 
detects  using  the  mechanism  of  if-detected  daemons.  These  daemons  are  tiny  inference 
engines  that  look  for  a  class  of  situations  and  perform  inferences,  such  as  detecting  goals 
for  UC,  when  the  class  is  matched  by  the  current  situation.  Besides  detecting  goals,  if- 
detected  daemons  are  used  to  suggest  plans  for  satisfying  the  newly  detected  goals.  By 
indexing  plans  according  to  the  type  of  situation  in  which  those  plans  are  commonly 
found  to  be  useful,  UCEgo  can  avoid  considering  inappropriate  plans  and  so  avoid 
inefficient  backtracking.  Situations  for  suggesting  plans  include  not  only  the  goal  of  the 
plan  and  the  preconditions  of  the  plan,  but  also  appropriateness  conditions. 

After  a  UCEgo  adopts  a  plan,  it  is  further  refined  by  the  UCExpress  component. 
Since  UCEgo  can  only  carry  out  plans  consisting  of  speech  acts,  plan  refinement  is 
through  the  process  of  answer  expression,  which  for  UCExpress  has  two  phases,  prun¬ 
ing,  md  formatting.  In  the  pruning  phase,  UCExpress  marks  as  not  needing  generation 
(in  some  cases,  this  means  generate  a  pronoun)  those  concepts  that  KNOME  believes  the 
use  already  knows  or  that  are  already  present  in  the  conversational  context.  In  the  for¬ 
matting  phase,  UCExpress  uses  specialized  expository  formats,  such  as  examples  and 
similes  to  express  information  to  the  user  in  a  clearer  manner. 


2.  Current  Status 


UC  is  currently  implemented  in  both  Franz  LISP  and  Common  LISP.  It  runs  on 
Digital  Equipment  Corporation  VAX  machines  and  on  SUN  3  workstations.  UC  consists 
of  approximately  10,000  lines  of  LISP  code  and  13,000  lines  of  KODIAK  declarations  in 
linearized  form.  In  the  original  graphical  form,  UC’s  knowledge  is  encoded  in  approxi¬ 
mately  200  KODIAK  diagrams,  consisting  of  a  total  of  about  1000  absolutes,  2,000  rela¬ 
tions,  and  3,000  aspectuals.  UCEgo  contains  approximately  50  if-detected  daemons.  A 
typical  query  takes  UC  from  6  to  10  seconds  of  real  time  for  UC  to  respond  on  a  SUN 
3/140. 


3.  Directions  for  Future  Research 

One  of  the  biggest  problems  in  building  a  system  like  UC  is  the  knowledge  acquisi¬ 
tion  bottleneck.  It  is  very  difficult  to  determine  how  to  best  represent  the  concepts 
needed  by  UC,  and  also  very  time  consuming  to  enter  into  UC  knowledge  about  the  vari¬ 
ous  UNIX  commands  and  their  formats,  effects,  planters,  options,  preconditions,  etc. 
Even  with  more  than  200  KODIAK  diagrams  worth  of  knowledge,  the  present  version  of 
UC  only  covers  a  subset  of  the  UNIX  file  system  manipulation  commands.  It  does  not 
cover  UNIX  mail,  the  UNIX  shells,  the  editors  available  under  UNIX,  or  the  program¬ 
ming  environment  tools.  Even  UC’s  coverage  of  the  UNIX  file  system  is  quite  hapha¬ 
zard  since  many  of  the  commands’  options,  preconditions,  and  side-effects  are  incom¬ 
pletely  covered.  So,  to  extend  UC  with  enough  knowledge  that  it  could  solve  a  reason¬ 
able  proportion  of  a  user’s  problems  would  require  several  orders  of  magnitude  more 
knowledge  than  the  present  UC  system.  Acquiring  that  amount  of  knowledge  will 
require  a  better  knowledge  acquisition  method  than  hand-coding,  which  suffices  only  for 
experimental  prototypes  like  UC. 

The  UCTeacher  component  ([Martin,  1985]  and  [Wilensky  et  al.,  1986])  was  an 
attempt  to  apply  some  of  the  techniques  demonstrated  in  UC  to  the  task  of  acquiring 
knowledge  for  UC.  UCTeacher  used  parts  of  UC’s  natural  language  interface  to  acquire 
knowledge  about  UNIX  from  the  user.  It  took  advantage  of  UC’s  core  knowledge  about 
the  basic  form  of  UNIX  commands  to  understand  new  commands.  In  a  dialog  with  the 
user,  UCTeacher  followed  a  fixed  script  of  interactions  with  the  human  expert.  This 
approach  works  well  for  learning  new  concepts  that  are  just  minor  variations  on  previ¬ 
ously  understood  concepts.  However,  it  does  not  work  for  learning  completely  new  con¬ 
cepts.  For  example,  UCTeacher  could  acquire  knowledge  about  related  commands,  but 
could  not  be  used  to  acquire  knowledge  about  commands  that  have  radically  different 
formats  or  commands  whose  effects  cannot  already  be  represented  in  UC.  UCTeacher 
did  not  have  the  flexibility  to  acquire  significantly  different  concepts. 

If  a  system  like  UCTeacher  is  to  be  able  to  acquire  radically-new  knowledge,  it  can 
no  longer  follow  a  fixed  script  of  exchanges  in  its  dialog  with  the  human  expert.  Rather, 
it  needs  to  be  able  to  make  decisions  such  as  determining  what  information  to  ask  the 
expert  next.  It  also  needs  to  decide  when  to  confirm  newly  acquired  knowledge  by  para¬ 
phrasing,  and  when  to  ask  for  clarifications  such  as  examples,  definitions,  and 


-  172- 


justifications.  In  more  complex  cases,  when  the  information  from  one  expert  contradicts 
the  information  from  another,  the  system  needs  to  have  a  model  of  the  experts  in  order  to 
be  able  to  decide  whom  to  trust.  These  sorts  of  capabilities  are  indicative  of  an  intelli¬ 
gent  agent. 

I  believe  that  the  methodology  described  in  this  thesis  and  demonstrated  in  the 
UCEgo  component  of  UC  can  be  applied  successfully  to  build  an  intelligent  agent  for 
acquiring  knowledge.  Such  an  intelligent  agent  would  have  different  requirements  than 
UCEgo.  In  the  case  of  UCEgo,  UC  knows  more  than  its  user  and  takes  the  initiative  to 
correct  deficiencies  in  the  user’s  knowledge.  On  the  other  hand,  an  intelligent  agent  for 
knowledge  acquisition  would  know  less  than  its  user,  and  would  need  to  take  the  initia¬ 
tive  to  correct  deficiencies  in  its  own  knowledge  base.  Also,  a  knowledge  acquisition 
system  is  much  more  likely  to  have  many  different  active  goals  at  the  same  time,  one  for 
each  different  piece  of  information  that  the  system  will  need  to  acquire  in  order  to  learn  a 
new  concept.  The  problem  of  choosing  which  goal  to  address  first  will  require  develop¬ 
ment  of  a  calculus  of  relative  goal  values,  a  problem  that  was  finessed  in  UCEgo.  So,  an 
intelligent  agent  for  knowledge  acquisition  would  extend  the  methodology  described  in 
this  thesis  in  major  new  directions,  as  well  as  address  the  important  bottleneck  problem 
of  knowledge  acquisirion. 
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Appendix  A 
KODIAK 

The  common  ground  for  all  the  components  of  UC  is  the  knowledge  representation 
language  KODIAK  ([Wilensky,  1987]).  A  single  KODIAK  knowledge  base  serves  all  of 
the  different  components  of  UC  in  order  to  facilitate  the  sharing  of  knowledge.  The  use 
of  KODIAK  structures  for  diverse  purposes  in  different  components  helps  to  constrain 
the  form  of  the  stractures  and  makes  them  less  ad-hoc.  In  keeping  with  this  philosophy, 
an  attempt  is  made  in  UC  to  store  even  the  unshared  internal  knowledge  of  UC  com¬ 
ponents  in  the  common  KODIAK  knowledge  base.  In  the  case  of  UCEgo,  KNOME,  and 
UCExpress  (the  components  of  UC  described  in  this  thesis),  all  internal  knowledge  is 
represented  using  KODIAK.  Since  KODIAK  knowledge  structures  appear  throughout 
this  thesis,  this  appendix  presents  a  brief  description  of  the  KODIAK  reprpentation 
language  and  its  notation.  For  a  more  detailed  description  and  for  a  discussion  of  the 
motivation  behind  the  design  of  the  language,  see  [Wilensky,  1986]  and  [Wilensky, 
1987].  A  good  description  of  KODIAK  as  it  is  used  for  text  understanding  can  be  found 

in  [Nor/ig,  1987]. 


1.  Basic  KODIAK  Concepts 

KODIAK  is  a  semantic  network  style  representation  language.  There  are  three 
types  of  nodes:  absolutes,  relations,  and  aspectuals.  An  absolute  is  used  to  represent  to 
objects  (including  mental  objects)  and  events.  Examples  of  absolutes  include  PERSON, 
USER3,  and  FILE.  By  convention,  absolutes  are  written  in  upper-case.  Categories  of 
absolutes  or  relations  in  KODIAK  are  organized  in  a  hierarchy.  In  KODIAK  terminol¬ 
ogy,  a  category  is  said  to  dominate  its  sub-classes.  Through  inheritance,  sub-classes 
inherit  the  properties  of  their  dominators. 

Absolutes  or  relations  that  are  members  of  categories  are  termed  instances .  By 
convention,  instances  of  categories  are  denoted  by  appending  a  positive  integer  to  the 
name  of  the  category.  So,  the  absolute  USER3  is  an  instance  of  the  absolute  category, 
USER.  Through  inheritance,  instances  inherit  all  the  properties  of  their  categories.  An 
instance  can  be  dominated  by  several  categories,  so  KODIAK  allows  multiple  inheri¬ 
tance. 

Relations  encode  the  relationships  among  different  absolutes  and  relations.  Exam¬ 
ples  of  relations  include  HAS-PART,  CONTAINS,  and  HAS-INTENTION4.  Like  abso¬ 
lutes,  relations  are  written  using  upper-case,  and  instances  are  denoted  by  appending  a 
number  to  the  category  name.  Also  like  absolutes,  relations  are  organized  in  a  multiple 
inheritance  hierarchy.  Unlike  absolutes,  every  relation  has  one  or  more  aspectuals  that 
serve  as  its  arguments.  For  example,  the  aspectuals  of  HAS-PART  are  whole  and  part . 
By  convention,  aspectuals  are  written  in  lower-case,  and  the  aspectuals  of  relation 
instances  have  the  same  numeric  extension  as  their  relation.  An  aspectual  has  a  value , 
which  can  be  an  absolute,  relation,  or  another  aspectual. 
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For  example,  consider  how  to  encode  in  KODIAK  that  the  user  USERl  has  the 
name  “chin,”  then  one  would  use  a  relation,  HAS-USER-NAMEl,  which  is  an  instance 
of  the  relation  category  HAS-USER-NAME.  The  relation  HAS-USER-NAME  has  the 
aspectuals  user-name  and  named-user,  so  HAS-USER-NAMEl  has  the  correspond¬ 
ing  aspectuals,  user-name1  and  named-user1 .  To  encode  that  USERl  has  the  name 
“chin,”  the  value  of  named-userl  would  be  USERl,  and  the  value  of  user-name1 
would  be  “chin.”  This  is  shown  graphically  in  Figure  7.1. 
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Figure  7.1.  The  definition  of  names  in  KODIAK. 

Most  of  UC’s  KODIAK  knowledge  is  entered  into  UC  graphically  using  diagrams  such 
as  that  of  Figure  7.1.  This  particular  diagram  describes  how  names  are  encoded  in  UC. 
The  absolutes  in  the  diagram  are  depicted  by  wide  rectangles  and  include:  MENTAL- 
OBJECT,  NAME,  USER-NAME,  FILE,  USER,  USERl,  and  Chin.  The  relations  are 
depicted  using  small  squares  and  include:  STATE,  HAS-NAME,  HAS-USER-NAME, 
HAS-FILE-NAME,  and  HAS-USER-NAMEl.  Directed  lines  labeled  with  “D”  indicate 
that  the  node  from  which  the  line  originates  is  dominated  by  the  node  to  which  the  line 
points.  Similarly,  lines  labeled  with  “I”  indicate  that  the  originating  node  is  an  instance 
of  the  target  node. 

Aspectuals  are  depicted  either  explicitly  as  circles  or  implicitly  as  labels  on  lines 
originating  from  relations.  Examples  of  explicitly  depicted  aspectuals  include  nsmG, 
named-obj,  file-name,  named-file,  user-name,  named-user.  Implicit  aspectuals 
include  user-namel  and  named-userl .  The  line  labeled  “named-obj”  from  HAS- 
FBLE-NAME  to  named-file  means  that  named-file  is  an  aspectual  of  HAS-FILE- 
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NAME  and  that  this  aspectual  plays  the  same  role  with  respect  to  HAS-FILE-NAME  as 
the  aspectual  named-obj  does  to  HAS-NAME.  This  relationship  between  named-file 
and  named-obj  is  termed  a  role-play  relationship.  Its  use  is  restricted  to  aspectuals,  and 
its  meaning  is  somewhat  similar  to  the  dominate  relationship  between  two  absolutes  or 
two  relations.  This  role-play  relationship  among  aspectuals  allows  one  to  name  aspectu¬ 
als  using  a  convenient  alias.  One  can  refer  to  an  aspectual,  call  it  aspl,  of  a  relation,  rell, 
by  naming  rell  and  also  naming  any  other  aspectual  asp2,  provided  that  aspl  plays  the 
role  of  asp2  in  rell.  For  example,  one  can  refer  to  the  named-uS0r1  aspectual  of  HAS- 
USER-NAMEl  by  referring  to  either  the  object,  the  named-obj,  or  the  named-user 
ofHAS-USER-NAMEl. 

An  aspectual  that  is  not  depicted  in  this  diagram  is  the  truth-val  aspectual,  which  is 
an  aspectual  that  is  inherited  by  the  STATE  relation.  Since  HAS-NAME,  HAS-USER- 
NAME,  and  HAS-FILE-NAME  are  all  dominated  by  STATE,  they  all  inherit  this  aspec¬ 
tual  too.  The  value  of  a  truth-val  aspectual  can  be  either  TRUE  or  FALSE.  This  is  used 
in  UC  to  encode  the  truth  value  of  a  relation.  For  example,  if  HAS-USER-NAMEl  were 
to  have  the  truth-val  of  FALSE,  then  the  meaning  of  HAS-USER-NAMEl  would  be  that 
USERl  does  not  have  the  user-name  of  “chin.”  If  a  relation  does  not  have  an  explicit 
value  for  its  truth-val  aspectual,  then  it  inherits  the  default  truth-val  of  TRUE.  So  true 
relations,  such  as  the  present  HAS-USER-NAMEl  relation,  do  not  need  an  explicit 
truth-val  aspectual  with  value  TRUE,  because  this  is  an  inherited  default  value. 

In  the  diagram,  the  lines  labeled  “C”  originating  from  aspectuals  indicate  a  con¬ 
straint  on  the  possible  values  for  that  aspectual  or  any  aspectuals  that  it  dominates.  Such 
constraints  are  inherited  by  any  other  aspectuals  that  play  the  same  role  as  the  con¬ 
strained  aspectual  in  the  role-play  hierarchy.  For  example  the  name  aspectual  can  only 
have  as  a  value  something  that  is  a  NAME.  This  constraint  is  inherited  by  all  aspectuals 
that  play  the  same  role  as  name ,  such  as  user-name  and  file-name .  Note  that  user- 
name  is  further  constrained  to  only  have  values  that  are  of  a  particular  sub-class  of 
NAME,  namely  USER-NAME. 

The  specialized  terminology  of  KODIAK  is  summarized  in  the  following  table: 
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Term 

Meaning 

absolute 

a  KODIAK  entity  for  representing  objects  (including  mental 
objects)  and  events 

the  arguments  of  a  relation,  which  can  have  values 

category 

an  absolute  or  relation  that  represents  a  category  in  the  KO¬ 
DIAK  multiple  inheritance  hierarchy 

concept 

anv  absolute,  relation,  or  aspectual 

constrain 

the  possible  values  of  an  aspectual  can  be  limited  or  con¬ 
strained  to  be  filled  only  by  instances  of  particular 
categories.  These  are  called  the  constrainers  of  the  aspec¬ 
tual 

dominate 

a  category  may  dominate  a  sub-category  in  which  case  the 
sub-category  is  a  sub-type  of  the  parent  category,  which  is 
called  the  dominator  of  the  dominated  sub-category;  this 
forms  a  multiple  inheritance  hierarchy  in  which  dominated 
categories  inherit  from  their  dominators 

hypothetical 

an  ontological  marker  on  a  concept  to  note  that  it  does  not 
have  a  referent  in  the  real  world 

instance 

anv  absolute  or  relation  that  is  a  member  of  a  category 

relation 

a  KODIAK  entity  used  to  encode  the  relationship  between 
different  absolutes  and  relations;  relations  have  one  or  more 
aspectuals 

role-play 

an  aspectual  of  a  relation  often  plays  the  same  role  as  an 
aspectual  in  the  dominator  of  that  relation;  if  a  player  as¬ 
pectual  plays  the  same  role  as  another  role  aspectual,  then 
the  player  aspectual  inherits  the  constrainers  of  the  role  as¬ 
pectual;  role-play  links  are  many  to  many 

value 

aspectuals  have  values  that  can  be  other  absolutes,  rela¬ 
tions,  or  aspectuals 

Summary  of  KODIAK  Terminology. 


2.  Hypotheticality 

An  important  extension  of  KODIAK  in  UC’s  implementation  is  the  idea  that  con¬ 
cepts  can  be  hypothetical.  This  is  represented  as  an  ontological  marker  that  is  placed  on 
concepts  to  represent  the  fact  that  these  concepts  do  not  currently  have  real  extensions. 
For  example,  when  the  user  asks  UC,  “How  can  I  delete  a  file?  ,  the  representation  of 
“a  file”  would  be  a  hypothetical  instance  of  a  file,  say  FILES.  This  hypothetical  marker 
on  FILES  means  that  there  is  not  currently  an  actual  file  in  the  world  that  UC  believes  to 
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correspond  to  FILES.  This  can  be  contrasted  to  what  happens  when  the  user  asks,  “How 
can  I  delete  the  file  named  core?”  In  this  case,  “the  file”  is  understood  as  a  real  file  that 
has  the  name  “core.”  In  this  case,  UC  believes  the  user,  so  it  will  also  believe  that  there 
really  is  a  file  named  “core”  in  the  world.  So  this  file  is  not  represented  as  a  hypotheti¬ 
cal  file  by  UC. 

All  of  these  ontological  marks  are  relative  to  UC’s  world  view,  since  the  marked 
concepts  are  within  UC’s  internal  representation  of  the  world,  that  is,  they  are  “inside  the 
head”  of  UC.  This  means  that  a  concept  that  is  marked  as  hypothetical  is  one  that  UC 
has  not  identified  as  currently  having  an  extension  in  the  real  world.  This  does  not  mean 
that  there  may  not  exist  something  in  the  real  world  that  could  be  the  extension  of  the 
hypothetical  concept.  Nor  does  this  imply  that  UC  believes  that  the  concept  does  not 
have  a  real  extension.  It  merely  means  that  UC  currently  does  not  know  of  a  real  exten¬ 
sion  for  the  hypothetical  concept.  So  in  the  previous  example  of  a  hypothetical  file,  UC 
does  not  necessarily  believe  that  there  is  not  an  actual  file  that  the  user  has  in  mind.  UC 
merely  does  not  currendy  know  of  a  real  file  to  which  “a  file”  might  refer. 

Hypothetical  concepts  should  not  be  confused  with  abstract  concepts.  An  abstract 
object  is  something  that  does  not  have  a  physical  embodiment.  Thus  files,  operating  sys¬ 
tems,  and  organizations  are  ail  abstract  objects,  however  not  ail  instances  of  files,  operat¬ 
ing  systems,  or  organizations  are  hypothetical.  For  instance,  the  file  named  “core,” 
UNIX,  and  the  University  of  California  at  Berkeley  are  abstract  entities,  however  they 
are  not  hypothetical. 

In  UC’s  version  of  KODIAK,  abstract  objects  are  those  concepts  that  are  dominated 
by  the  category  MENTAL-OBJECT  as  opposed  to  those  dominated  by  the  category 
PHYSICAL-OBJECT.  Thus,  since  the  category  FILE  is  dominated  by  MENTAL- 
OBJECT  and  not  PHYSICAL-OBJECT,  all  files  are  abstract  objects.  Hypotheticality  is 
implemented  in  a  similar  fashion.  Hypothetical  objects  are  encoded  as  instances  of  the 
HYPOTHETICAL  category.  However,  unlike  abstract,  the  distinction  of  hypotheticality 
extends  to  relations/propositions  as  well  as  to  objects.  All  relations/propositions  can  be 
considered  abstract,  but  not  all  relations/propositions  are  hypothetical. 

The  notion  of  hypothetical  applies  to  relations/propositions  through  the  classical 
philosophical  notion  that  the  referent  of  a  proposition  is  its  truth  value.  Thus  the  proposi¬ 
tion,  “I  own  a  Ferrari  Testarossa,”  is  hypothetical,  since  it  is  not  true  that  I  now  own  a 
Ferrari  Testarossa.  On  the  other  hand,  the  proposition,  “I  wish  that  I  owned  a  Ferrari 
Testarossa,”  is  not  hypothetical,  since  it  is  true  that  I  now  wish  that  I  owned  one.  In 
terms  of  KODIAK  relations,  “I  wish  that  I  owned  a  Ferrari  Testarossa,”  would  be 
represented  as  two  relations,  HAS-GOALl  and  HAS-OWNERl  as  shown  in  Figure  7.2. 
HAS-OWNERl  represents  the  proposition,  “I  own  a  Ferrari  Testarossa,”  while  HAS- 
GOALl  encodes  “I  wish  that  HAS-OWNERl.”  HAS-GOALl  has  the  aspectual 
plannerl ,  which  has  the  value  PERSONl  (representing  “I”),  and  the  aspectual  goal1  , 
which  has  the  value  HAS-OWNERl.  The  relation  HAS-GOALl  has  the  ownarl  aspec¬ 
tual  with  the  value  PERSONl,  and  an  owned-obj  aspectual  with  the  value  TES- 
TAROSSAl  (representing  “Ferrari  Testarossa”).  In  this  case,  HAS-GOALl  is  not 
hypothetical,  since  it  is  true  that  PERSONl  has  the  goal  of  HAS-OWNERl,  but  HAS- 
OWNERl  is  hypothetical,  since  it  is  not  true  that  PERSONl  owns  TESTAROSSAl. 
Note  also  that  PERSONl  is  not  hypothetical,  since  the  speaker  is  a  real  person,  whereas 
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TESTAROSSAl  is  hypothetical,  since  there  is  no  particular  Ferrari  Testarossa  that  is  the 
subject  of  discussion. 


Figure  7.2.  KODIAK  representation  of  “I  wish  that  I  owned  a  Ferrari  Testarossa.” 

Although  a  hypothetical  proposition  is  not  necessarily  true,  it  is  not  necessarily  false 
either.  For  example,  if  the  user  were  to  state,  “I  suspect  the  machine  is  down,”  then 
“the  machine  is  down”  is  hypothetical,  since  UC  does  not  have  enough  information  to 
form  a  belief  about  whether  the  m.achine  is  really  down  or  not.  Similarly  in  the  previous 
example  about  wanting  to  own  a  Testarossa,  the  fact  that  HAS-OWNERl  is  hypothetical 
does  not  imply  that  PERSONl  does  not  own  a  Testarossa.  That  may  be  inferable  from 
the  fact  that  the  person  wants  to  own  one.  However  it  is  a  not  necessary  consequence, 
since  it  is  conceivable  that  PERSONl  has  amnesia  and  does  in  fact  own  a  Testarossa. 

The  hypothetical  marker  serves  two  main  purposes  in  UC.  The  first  purpose  is  so 
that  UC  can  tell  if  propositions  in  its  knowledge  base  are  true.  So  in  the  example  of  the 
user  asking,  “How  can  I  delete  the  file  named  core?”  UC’s  goal  analyzer  will  deduce 
that  the  user  has  the  goal  of  the  user  knowing  how  to  delete  the  file  named  core.  This  is 
represented  in  UC’s  knowledge  base  as  the  HAS-GOAL3  relation  with  aspectual  goal3 
having  the  value,  KNOW3,  which  is  hypothetical.  Later,  if  UC  were  to  look  in  its 
knowledge  base  to  see  whether  the  user  knows  how  to  delete  the  file  named  core,  it  will 
find  KNOW3  and  realize  through  the  hypothetical  marker  that  this  does  not  mean  that  the 
user  does  know.  Without  the  hypothetical  marker,  UC  would  not  be  able  to  tell  that 
KNOW3  is  not  a  real  fact  even  by  inspecting  ail  the  relations  in  which  KNOW3  partici¬ 
pates  and  finding  that  it  is  part  of  the  HAS-GOAL3  relation.  Even  this  does  not  work, 
since  participating  as  the  goal  in  a  HAS-GOAL  relation  does  not  necessarily  mean  that 
the  participant  is  not  true.  It  is  plausible  that  the  planner  might  want  something  that 
already  holds.  For  example,  a  planner  may  want  the  sky  to  be  clear  even  when  the  sky  is 
clear. 

The  second  purpose  of  the  hypothetical  marker  is  to  replace  variables.  In  UC, 
hypothetical  concepts  are  used  in  place  of  the  variables  found  in  ordinary  programs.  For 
example,  if  the  rule,  to  delete  ?x  where  ?x  is  a  file,  type  rm  followed  by  ?x,  were 
represented  in  UC,  then  the  variable  ?x  would  be  represented  in  UC  as  a  hypothetical 
instance  of  a  file.  Then  a  rule  applier  could  match  the  hypothetical  file  to  any  other 
instance  of  a  file.  Such  replacement  of  variables  is  possible,  since  the  great  majority  of 
“variables”  in  UC  are  type-constrained  as  in  the  previous  example  where  ?x  is  con¬ 
strained  to  be  a  file.  In  those  infrequent  cases  where  there  are  no  such  constraints  on  the 
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variable,  UC  can  use  a  hypothetical  instance  of  the  category  SOMETHING,  which  is 
unconstrained,  since  all  other  categories  are  dominated  by  SOMETHING. 

Replacing  variables  with  hypothetical  markers  on  concepts  emphasizes  the  fact  that 
variables  in  UC  are  first  of  all  concepts  and  only  secondly  variables.  Hypothetical  con¬ 
cepts  are  considered  variables  in  the  sense  that  UC  does  not  know  of  a  referent  for  the 
hypothetical  concept  in  the  real  world.  When  a  hypothetical  concept  is  found  to  match  to 
a  real  concept,  then  the  referent  of  the  hypothetic^  concept  has  been  found:  its  referent  is 
the  real  world  referent  of  the  matching  real  concept.  In  the  case  where  a  hypothetical 
concept  is  found  to  match  another  hypothetical  concept,  then  this  is  equivalent  to 
unification  of  variables. 

In  keeping  with  the  convention  of  prepending  a  “?”  to  variables,  hypothetical  con¬ 
cepts  are  marked  in  UC  by  appending  a  “?”  to  the  name  of  the  concept.  This  convention 
is  built  into  UC’s  printers  for  output  so  that  hypothetical  concepts  can  easily  be 
identified.  The  convention  is  optional  for  input  of  KODIAK  concepts  to  UC. 

The  hypothetical  marker  is  only  a  partial  solution  to  the  problem  of  representing  the 
ontological  status  of  concepts.  It  does  not  even  address  some  of  the  issues  dealt  with  by 
possible  world  semantics.  However,  it  has  proven  sufficient  in  UC  for  distinguishing 
between  those  concepts  that  the  system  believes  and  other  concepts  in  UC’s  knowledge 
base.  More  importantly,  the  marker  is  an  improvement  over  traditional  variables.  It  pro¬ 
vides  a  simple  means  of  encoding  type  constraints  on  variables  that  fits  extremely  well 
into  the  framework  of  hierarchical  conceptual  network  systems. 
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Appendix  B 

UNIX  Commands 

The  following  table  lists  the  UNIX  commands  that  are  mentioned  in  this  thesis  and 
their  main  uses. 


Command 


chmod 


compact 


Is 


Is  -i 


Is  -1 


mkdir 


rmdir 


ruptime 


nvho 


spice 


Usage  


concatenate  and  print  files _ 


change  the  protection  of  files _ 


compress  files _ _ 


copy  files  _ _ _ 


compare  files  _ _ 


list  disk  usage  statistics _ 


extensible  editor  that  runs  on  many  systems _ 


list  information  about  users  _ _ 


search  a  file  for  a  pattern _ 


terminate  processes _ 


print  a  file _ _ 


list  file  names  _ 


list  files  and  their  inodes  _ _ 


list  files  and  their  protections _ _ 


create  directories  _ 


text-file  contents  perusal  program 


move  or  rename  files  _ 


list  the  status  of  processes _ 


copy  files  over  the  network _ 


remove  files _ _ 


remove  directories  _ 


read  news  _ _ 


fantasy  game _ 


list  the  uptime  of  all  machines  on  the  network _ 


list  the  current  users  for  all  machines  on  the  network 


list  spelling  errors  in  a  file _ 


electronic  circuit  simulation  program _ 


terminal  dependent  initialization _ _ 


list  the  uptime  of  the  machine _ 


visual  display  editor _ 


list  the  current  users  of  the  machine  _  _ 
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